Adaptively Scheduling Playback or Presentation, based on User Action(s)

ABSTRACT

Methods and apparatus for providing a personalized entertainment experience, which may be customized for each user. A user&#39;s playback/presentation history and/or user actions may be captured and associated with each played/presented composition. A target time for playback/presentation of a composition to the user may be determined by using a user&#39;s playback/presentation history and/or user actions. The target time for playback/presentation may incorporate a target time between playbacks/presentations of a composition, which may be at least partially based on a user&#39;s playback/presentation history and/or user actions. A customized sequence of compositions may be automatically generated for each user. The personalized sequence may automatically adapt to changing user actions and preferences over time.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part (CIP) of U.S. applicationSer. No. 12/910,139 filed on Oct. 22, 2010 entitled “AdaptivePersonalized Music and Entertainment”; which is a continuation-in-part(CIP) of U.S. application Ser. No. 11/161,710 filed on Aug. 12, 2005entitled “Distributing Digital-Works and Usage-Rights to User-Devices”,now U.S. Pat. No. 8,001,612; and is a continuation-in-part (CIP) of U.S.application Ser. No. 10/605,879, filed on Nov. 3, 2003, entitled“Adaptive Personalized Music and Entertainment”, now U.S. Pat. No.7,884,274. These earlier applications, in their entirety, areincorporated by reference into this specification.

BACKGROUND

Existing methods for entertaining a listener (or viewer) with music ormusic videos (or other entertainment) have numerous limitations thatresult in a less than an ideal user experience.

A major limitation with broadcast media such as radio and television isthat the user has no control over the channel stream. If the listenerdoes not like the current composition, the listener's only option is tochange to another station or channel. However, there are typically alimited number of alternate channels of music suitable for the user. Inaddition, to switch quickly to a suitable alternative channel requiresthe user to have found and pre-selected the alternate channels ofinterest. When the user does switch channels, the new channel will mostlikely be somewhere in the middle of a composition, advertisement orother audio presentation. Recently commercial-free radio is beingoffered via satellite radio (e.g., XM Radio) and some internet radiostations, but the music is not customized to each user. Another majorlimitation of broadcast is that there is no link between the broadcaststream and the user's music collection. If the listener does hear a songthey would like to add to their music collection, they typically need toremember the artist, album and song so it can be located or acquired atsome later time. Often, the information needed to acquire a song(artist, album, title, etc) is not available at broadcast time when thelistener is interested in it.

A major limitation of purchased albums on media such as CD's, DAT,tapes, and DVD's is that the user must expend considerable effort to beable to identify what they want and then to locate the media at a vendorand then purchase it. In order to purchase a media, the listener must beable to identify the specific album desired by artist and album name.Each purchased media may include many compositions that the user doesnot want. Sometimes the listener may purchase the wrong album bymistake. Once purchased, the listener must provide physical storage forthe media and then later locate and insert the media to playback thecompositions. To playback a particular song, the user must remember theparticular media (e.g., CD) the song is located on and then be able tofind that specific media among perhaps 100's of similar looking media.The user must also coordinate and physically transport the media betweenthe user's various locations and user-devices (e.g. home, car, portableplayer, etc). Often, a desired album's media may not be at the desireduser's location. In addition, media players hold only a limited ofnumber of media so the user is limited to a playback stream from alimited number of albums at any one time. For certain locations, such asin an automobile, the locating, handing and inserting the media may be asafety distraction. The order of playback is limited to the compositionorder on the media, the random ordering of the media compositions and/orperhaps a playlist the user manually defines. The media is subject toscratching or other physical damage, requiring the user to create backupcopies or purchase replacement copies. The physical media may have aphysical lifetime which is much shorter then the users. In addition, dueto the rapid rate of technological change, vendor support for a givenmedia format may be less than the user's lifetime.

An emerging technology is the storage and management of the user's musiccollection on the user's personal computer (PC). With compressiontechnology (such as MP3 or WMA formats), approximately 2500 (near CDquality) songs can be stored per 10 Gbyte of hard disc capacity. SincePC's with 30 to 100+ Gbyte discs are now commonly available, now or inthe near future, PC's will have sufficient capacity to hold a user'sfull music collection in compressed format. The user's collection istypically managed on the PC by interactive windows driven software,which the user must install and learn to use. The user must expend asignificant effort to build their collection of compositions. The usermay expend significant effort to convert their previously purchasedmedia (such as CD's) into suitable compressed files on the PC harddrive. Even using high read/write rate drives, such a conversion couldtake 3 to 10 minutes per CD and 5 to 16 hours for a collection of 100CD's. The quality of the compressed file is determined by the user'sability to operate the compression software and select the appropriatecompression settings for each composition.

An emerging way of building a music collection on the user's PC is thepurchase and down load of songs in a suitable compressed format acrossthe internet. The major providers of downloadable songs includePressPlay, AOL MusicNet, FullAudio MusicNow, and MusicMatch. Users usethe PC to locate, purchase and download new songs over the internet. Amajor limitation of this approach is that the user must be able toidentify the artist, album and song by name. Disadvantages include thatthe user must manually locate each song within the catalog of songs inthe provider's database, by typically either reading through analphabetical list of songs by musical category (genre), artist, album;or alternatively by performing a search for each song via a search tool.They may have to navigate a separate set of web pages to locate anddownload the composition. In some cases, a web page may provide a shortsample of a song which may be heard before purchasing and downloadingthe full song. The user may have to wait while the download isoccurring, in order to verify it downloaded correctly. An additionaldisadvantage is that the additional cost of the PC may exceed the costof the user-devices. In addition, the user must learn to use the PC andits software. The user must manage the downloaded composition once it'sbeen downloaded. The user may have to manually create playlists andlater relocate the user created playlists by the playlist name.

Some users have built a portion of their collection via music piracy andfile sharing software, often using peer-to-peer networks across theinternet. The user faces ethical and legal issues. The user facesadditional security and privacy issues associated with the peer-to-peernetworks and the associated software such as viruses, worms, spyware,and stealth software. In addition, the quality of each music file isunknown and not guaranteed, since there are multiple good, marginal, badand bogus versions of each song out on the network. The user must expendeffort to locate the artist, album and song. Then, after waiting for thedownload to complete, the user must determine if the quality of thedownloaded song is acceptable, and begin the process again if thequality is insufficient. The quality of the pirated song may be wellbelow the quality of the original version.

Once the collection is built, the user must manage their collection ofsongs on the PC storage device. Using windows driven software on the PC,the user must manually select among the songs in their collection tocreate one or more playlists. In addition, the user must periodicallyback-up their collection on the PC to protect against loss due to drivefailure, fire, damage or theft. For large collections, this is soinconvenient and time consuming; it is often not done frequently enoughor not done at all, placing at risk of loss all of the user's efforts inbuilding their collection. There are many competing file formats (MP3,WMA, AAC, etc), which only operate with certain vendor's hardware and/orsoftware. The formats are constantly evolving and may have a limitedvendor support lifetime. The user's collection in a particular formatmay no longer be supported at some point in time, requiring considerableuser effort to convert the collection into another supported format, ifa conversion is even possible.

Several new types of music players, including portable players, haveemerged that are capable of handling compressed storage formats. Theuser's collection and playlists for these devices are typically managedvia interactive windows software on the user's PC. For players withlimited storage capacity (e.g., SonicBlue Rio MP3 player), PC softwareis used to select a limited portion of the user's collection, which isthen sent to the player's memory over a cable or loaded onto memorymedia or a memory device which the user can insert into the portableplayer. Some recent players (such as Apple's iPod, Creative's NomadJukebox Zen, or PhatNoise's PhatBox) have large enough hard disc storage(10 to 30 Gbyte) to hold a collection of up to 2000 to 8000 songs. Someplayers (e.g., the Apple iPod) auto-synchronize with the PC by plugginginto a high rate interface cable. The PhatBox player, intended forinstallation in automobiles has a removable hard disk cartridge thatattaches to a PC cradle (USB 2.0 cable) for content management. Theuser's collection and the creation of user playlists are managed on thePC via interactive windows based software.

Another emerging technology is user customized radio via streamingacross the internet, such as Yahoo LaunchCast. An automaticallygenerated sequence of songs, custom selected based on the user'sprofile, is generated remotely at the service providers server. Thestream is forwarded to the user across the internet to a playerapplication located on the user's PC. Each user creates a unique profileusing an interactive windows application on the PC in-order to selectmusic categories and artists the user likes. The user also may provideadditional profile feedback, while a composition is playing or byaccessing the user's library, to rate each song, album and artist on arating scale. A major disadvantage of LaunchCast is that there is nolink between the user's radio profile information and the user's musiccollection [i.e., the user's usage-rights (e.g., listening-rights) toparticular compositions]. Because there is no link with the user'susage-rights, the LaunchCast user does not have the ability to go“backward” or to repeat a song or cause a particular song to play. Ifthe user wishes to add a composition that is playing to theircollection, they are only provided with a link to a web page where theCD may be purchased. A disadvantage of streaming is the skipping orjumps that occur if the continuous virtual bandwidth is interrupted byother network traffic. Another disadvantage of streaming is its limitedtolerance to insufficient network latency, which can result in delays inthe radio program, especially when the user decides to “forward” or“skip” over the currently playing song.

Other interactive internet based streaming services allow the user tocreate a custom playlist or multiple playlists of favorites, byselecting each song to include from a catalog of compositions providedby the service. A major limitation is that the user must be familiarenough with the composition to be able to identify the artist, album andsong by name. In addition, the user must expend considerable effort tomanually locate each song within the catalog of songs in the provider'sdatabase or the user's library, by typically either reading through analphabetical list of songs by genre, artist, album or performing asearch for each song by using a search tool. The user must continuallyand manually update all this as their musical tastes change over time.To generate a stream of songs, the user may then have to choose a groupor order of particular songs to form a user's custom playlist. Anotherlimitation is the user does not own the music collection and does notown usage-rights to the music. In addition, it is not integrated toother usage-rights the user already has purchased.

In some internet services, the user may indicate the relative likeablityof each of the songs in their custom playlist. Typically, the usermanually rates each composition based on a scale, such as 1 to 100.Which requires the user to manage in their mind the relative rankings ofsongs by rating number so one song has a higher number relative toanother. In addition, the user must manually change their ratings andtheir playlists as their taste for songs changes over time. Thistypically requires a significant amount of visual interaction from theuser, often with a PC windows based display, which is not suitable whiledriving an automobile or for many other activities.

The Apple iTunes system is currently one of the most popular methods forpurchasing music on-line. When a user makes an on-line purchase, theusage-rights and composition is typically downloaded and then storedlocally on the hard disk of a user's personal computer (PC). With AppleiTunes, a user may only be allowed to download the composition once (ora limited number of times) per purchase. A user may lose their purchasedusage-rights if this local user-device (typically a personal computer)is damaged, destroyed, lost, stolen, etc. If lost, the iTunes song mustbe purchased a second time before it can be downloaded again.

To protect their iTunes collection from loss, users are responsible forbacking up their collection of compositions by copying them from thepersonal computer to an external storage device or media. Without abackup copy, any damage or loss of the personal computer's hard diskwill result in an unrecoverable loss of the user's collection and theuser would be required to repurchase and rebuild their collection againfrom scratch. Many users do not perform regular backups because of thetime and effort involved. Even when backups are done, users often keeptheir backup copies in close proximity to their computer hard drive,which may not protect against loss or damage from a fire or theft.

With Apple iTunes, a purchased song may be authorized for use on only 5user-devices (of an authorized type) at a time. The user is required toperform a complicated procedure to transfer a song and obtainauthorization to use the song on each new user-device. In order toauthorize the use of a song on a new user-device, the user may berequired to enter the Apple-ID and password used to purchase the song.When the 5 user-device limit is reached, the user is also required tomanually de-authorize a song on one user-device so it can be authorizedon another user-device. The user must also remember to de-authorizetheir computers and user-devices whenever they are sold, given away orare serviced.

Transfers of iTunes usage-rights to other user-devices (such as aportable player) are typically accomplished by a cable or local areawireless connection between the PC and the second device. This typicallyrequires the other user-devices to be brought near the PC or local mediaserver where the user's usage-rights are stored. In addition, the usermust plan and coordinate bringing the devices together whenever atransfer of usage-rights is desired. Such transfers are particularlydifficult when the user-devices are at different physical locations(such as home, work, automobile, etc.) or are not easily portable.

Overall, an iTunes user must expend significant time and effort toacquire, download, backup, and transfer songs between their user-devicesand to authorize/de-authorize their collection of songs at eachuser-device.

Today, a given user-device is typically compatible with only one or alimited number of the many different file formats,compression-decompression algorithms and content-protection methods.Vendors such as Microsoft, RealNetworks and Apple may use proprietary orindustry standard (MP3, MPEG-4) approaches. These are often notinteroperable. Digital content packaged for one vendor's user-devices(e.g., Apple) may not be playable on another vendor's user-devices(e.g., Microsoft Windows Media). In addition, new, different andimproved formats, compression-decompression algorithms andcontent-protection methods are expected to be introduced in the future.

Today, the content-protection methods are typically based on proprietarydigital rights management (DRM) approaches that are unique to eachvendor's user-devices. Examples of DRM solutions include InterTrust(Rights System), RealNetworks (Media Commerce Suite), Windows Media(Rights Manager) and Widevine Cyper.

When the user purchases digital content (e.g., a composition) today, itmay only play on the user-devices from a single vendor. For example, ifa user purchases a song from the Apple iTunes Music Store, it can onlybe played using an iTunes jukebox (Apple software) on the user's PC orusing an Apple hardware device such as an Apple iPod portable player.

Today, the large number of incompatible choices confuses consumers andreduces sales because consumers are uncertain about what to buy and areafraid of buying soon-to-be obsolete products. Consumers recognize thatmany different media products that are introduced in the marketplacequickly die (for example, Beta VCR tapes). Consumers are also concernedthat new technology will be introduced in the near future that will maketheir purchased user-devices and composition formats obsolete (forexample, vinyl LP records). Today, many consumers may decide to delaypurchases of user-devices and their corresponding compatibledigital-content (e.g., digital-works) until a technology approachbecomes the established industry standard.

More generally, the above discussion may also apply to any type ofdigital-work including music, music videos, multi-media, artwork,pictures, audio, sound, short films, movies, video clips, televisionprograms, audio versions of books, talks, speeches, voice content,lectures, software, software plug-ins and any other type ofdigital-work. In some cases, the media formats will differ (DVD's orother formats instead of CD's), but the limitations discussed aregenerally applicable.

SUMMARY

Methods and apparatus for providing a personalized entertainmentexperience, which may be customized for each user. A user'splayback/presentation history and/or user actions may be captured andassociated with each played/presented composition. A target time forplayback/presentation of a composition to the user may be determined byusing a user's playback/presentation history and/or user actions. Thetarget time for playback/presentation may incorporate a target timebetween playbacks/presentations of a composition, which may be at leastpartially based on a user's playback/presentation history and/or useractions. A customized sequence of compositions may be automaticallygenerated for each user. The personalized sequence may automaticallyadapt to changing user actions and preferences over time. The user'scollection of compositions may be automatically integrated with thegenerated customized sequence. In one embodiment, a target time for nextplayback/presentation may incorporate a time betweenplayback/presentation, which is at least partially based on rating(preference) of the user for the composition. The user rating(preference) may be explicitly provided by the user or may be implicitlydetermined at least partially based upon controls or action(s) by theuser, that are related to the composition.

Apparatus and method for providing an adaptive personalizedentertainment experience that is customized for each user. Details ofplayback or presentation of a composition to a user may be captured atone or more use-devices. The captured details may include user actionsand user control actions that are associated with each played orpresented composition, and captured as user feedback about eachcomposition. A target time for the playback or presentation of acomposition to a user, and/or a targeted time between playbacks orpresentation of a composition to a user, may be determined by using thecaptured details of the playback or presentation of compositions. Acustomized sequence of compositions may be automatically generated foreach user by utilizing a history of the details of playback and/orpresentation associated with the user; and/or the user actions and/orcontrol actions. The personalized sequence may automatically adapt tochanging user preferences and feedback over time.

A method and system for providing a personalized entertainmentexperience that is customized for each user. User actions and usercontrol actions may be associated with each played composition andcaptured as user feedback about each composition. A targeted timebetween playbacks of a composition may be determined by using saidcontrol actions. A customized sequence of compositions may beautomatically generated for each user by utilizing a history of the useractions and/or control actions. The personalized sequence mayautomatically adapt to changing user preferences and feedback over time.The user's collection of compositions may be automatically integratedwith the generated customized sequence. Additional compositions andsamples, that are new to a user, may be automatically chosen based onthe prior user feedback/history and may be added to the user'scollection when indicated by user action(s).

There are many objects and advantages of the disclosed embodiments, whencompared with the existing state of the art. The objects and advantagesmay vary with each embodiment. The objects and advantages of each of thevarious embodiments may include different subsets of the followingobjects and advantages:

-   -   Provide a simplified way providing an entertainment experience        that is customized for each user.    -   Allow the user to experience both different and new        compositions, more easily and at a faster rate.    -   Simplify the process of finding and acquiring a larger variety        of pleasing compositions for each user's collection.    -   Simplify the purchase and delivery of compositions to create a        user's collection.    -   Not require the user to identify and select compositions based        upon knowledge of the composition such as composition title,        artist's name, or album name.    -   Protect a user's collection of compositions against the theft or        loss.    -   Eliminate all user efforts and concerns with backing-up and        storing their personal collection of compositions        (digital-works).    -   Preserve a user's profile, history and collection even if        user-devices are lost, stolen, broken or destroyed.    -   Eliminate user efforts of knowing, locating or converting        different file formats for different user-devices and future        user-devices.    -   Allow each user's profile, history and collection to be        available to all the user-devices wherever they are located or        used. Allow each user's profile, history and collection to be        immediately available to any user-device not previously used by        the user (a new purchase, a friend's, etc.).    -   Automatically manage the user's collection of compositions.        Allow user's compositions to be usable anywhere the user is.        Automatically distribute, as needed, the user's compositions        (collection) to any user-device where the user is active.        Eliminate all user efforts to transfer their compositions        between user-devices.    -   Allow each user's profile, history and collection of        compositions to be usable with all experience-providers. Allow        the user to easily switch between experience providers.    -   Maintain privacy and anonymity of each user's profile, history        and collection of compositions.    -   Adapt to each individual user's control actions, representing        real-time feedback of likes and dislikes of compositions while        they are played.    -   Adapt to changing user tastes, such as when a user becomes tired        of a given composition.    -   Utilize the prior experiences of other similar users, to improve        each user's experience.    -   Allow aggregate real-time information collected from the many        users to influence decisions made by the experience-providers,        composition-providers and composition creators.    -   Provide a simple and intuitive user interface that is similar to        existing user-devices that users are already familiar with.    -   Allow users to share a favorite composition or their current        list of favorites with each other.    -   Protect compositions against piracy.    -   Provide such a superior experience and ease of use (compared        with pirated alternates) that user's will prefer to pay for such        convenience.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates the capture of user control actions representing userfeedback about a currently playing composition.

FIG. 2 illustrates the functional flow between user-devices,experience-providers and composition-providers and (optional)identity-providers.

FIG. 3 is a functional diagram of a user-device such as a personalizedmusic player.

FIG. 4 illustrates an embodiment of a user interface for a user-devicewith manual controls.

FIG. 5 illustrates an embodiment of a user history database.

FIG. 6 illustrates the functional flow of a Real-time SequenceGenerator.

FIG. 7 a illustrates typical relationships of “user likeability orenjoyment (rating/preference)” versus the “number of times heard(play-count)”.

FIG. 7 b illustrates typical relationships of “time between plays”versus the “number of times heard”.

FIG. 7 c illustrates a typical relationship of “time between plays”versus “(current enjoyment)/(peak enjoyment)”.

FIG. 7 d illustrates a typical relationship of “time between plays”versus “user rating or preference”.

FIG. 7 e illustrates a typical relationship of “maximum time betweenplays” versus “user rating or preference”.

FIG. 7 f illustrates a typical relationship of “minimum (at least this)time between plays” versus “user rating or preference”.

FIG. 7 g illustrates a typical relationship of targeted minimum &maximum “time between plays” versus “user rating or preference”.

FIG. 7 h illustrates a typical relationship of “time between plays ”versus “user rating or preference” for manually input and automaticallydetermined ratings.

FIG. 7 i illustrates an example of a linear relationship of “timebetween plays” versus “user rating or preference”.

FIG. 7 j illustrates an example of a non-linear relationship of “timebetween plays” versus versus the “number of times heard (play-count)”.

FIG. 8 illustrates a process for recommending new compositions and newhighlights for a user.

FIG. 9 illustrates an embodiment of an Aggregate Common LikeabilityDatabase.

FIG. 10 illustrates an alternate embodiment of an Aggregate CommonLikeability Database.

FIG. 11 shows examples of relationships of “updated time betweenplaybacks” versus the “prior time between plays” and “user action”.

FIG. 12 is functional diagram of an embodiment of the user usage-rightsmanagement at a user-device.

FIG. 13 illustrates an example of the contents of a usage-rights token(ownership token).

FIG. 14 shows an example of the acquisition of usage-rights for a user.

FIG. 15 shows an embodiment of an identity-provider creating ananonymous-ownerID and login-Info; and providing banker functions.

FIG. 16 illustrates an example of the contents of a playback history.

FIG. 17 illustrates an embodiment of the contents of a record of asingle playback.

FIG. 18 illustrates an embodiment for distributing digital-works to auser-device.

FIG. 19 illustrates an embodiment for distributing digital-works to auser-device.

FIG. 20 shows examples of relationships of “updated time betweenplaybacks” versus the “prior time between plays” and “user action”.

FIG. 21 shows examples of relationships of “updated time betweenplaybacks” versus the “prior time between plays” and “user action”.

FIG. 22 shows a flow chart of one embodiment for automaticallydetermining the magnitude of the rating of a user for a specificcomposition by using actions by the user.

FIG. 23 shows one embodiment of a flow chart for determining when aparticular composition will be played for the user again

FIG. 24 a-24 d shows examples of the relationships between a rating andaction by a user.

FIG. 25 a-25 b shows examples of the relationships between a rating; andboth newer action by a user and prior action(s) by a user.

FIG. 26 a-26 b shows examples of the relationships between the “timebetween playbacks” and action by a user.

FIG. 26 c-26 d shows examples of the relationships between the “timebetween playbacks”; and both newer action by a user and prior action(s)by a user.

DETAIL DESCRIPTION

Although some of the following detailed embodiments are illustrated ordescribed in terms of audio or musical compositions, the disclosedconcepts and embodiments are more generally applied to any type ofcomposition, digital-work or digital-content including recorded-music;music videos; multi-media; artwork; pictures; audio; sound; short films;movies; video clips; television programs; audio versions of books;talks; speeches; voice content; lectures; software; software plug-ins;and any other type of digital-work.

In general, where the word “composition” is used in the description,“digital-work” or “digital-content” may be substituted in its place.Where the words “playback-device” or “player” or “media-player” is usedin the description, “user-device” may be substituted in its place. Wherethe word “composition-provider” is used in the description,“digital-work-provider” or “digital-content-provider” may be substitutedin its place.

Distribution of Compositions:

FIG. 2 illustrates the functional flow between user-devices 21,composition-providers 23, experience-providers 26 and usage-rightsrepositories (usage-rights authorities) 24 across one or more networks27.

As shown in FIG. 2, there may be a plurality of possible users 21(userl, user2, . . . , user“z”) . Each user may operate one or more useruser-devices 22 at different times and different locations such as athome(s), work(s), automobile(s), portable(s), etc. A user-device 22 iscapable of utilizing one or more types of digital-works. User-devicesmay also be incorporated into other products such as a cell phone,television or home entertainment system. The user-devices may be mobileand portable. Some user-devices (i.e., a personal player) may be used byonly a single individual user. Other user-devices (i.e., an automobileplayer) may be operated by different individuals at different times. Theuser-devices may be manufactured by many different vendors. Any givenuser-device 22 may only be able to handle only certain types ofdigital-works and may only be able to handle a subset of the availablecomposition formats.

There may be many composition-providers 23 that each provide their owncatalog of compositions for which they control the intellectual propertyrights. A composition-provider 23 may control the compositions for asingle composition creation entity [i.e., the creative artist(s) orgroup] or many composition creation entities.

There may also be many different experience-providers 26. Anexperience-provider 26 is responsible for providing the adaptivepersonalized entertainment sequence that is customized for each user andis integrated with the user's collection of compositions. Theexperience-provider 26 may automatically introduce the user toappropriate new compositions over time and automatically adopt thepersonalized program sequence as a user's tastes change. Theexperience-provider 26 automatically distributes the user's collectionand also automatically collects and maintains the user's profile andhistory across all the user-devices. The user's collection is madeavailable to any user-device 22 that the specific user is operating.

There may also be one or more usage-rights repositories (usage-rightsauthorities) 24. The usage-right repository utilizes a common “standardfor usage-rights tokens” 25 so that a user's collection of compositions,represented by the set of usage-rights tokens a user acquires, may berecognized and usable with all experience-providers. Each usage-rightstoken may be defined to limit use to only a specific individual user ora group of specific users (e.g., a family). The tokens representing thecompositions in a user's collection may be easily transferred betweenand used with any of the experience-providers. The usage-rightsrepository may maintain a database of all issued tokens so a user'scollection (usage-rights tokens) may be preserved even if all theuser-devices of a user were to be lost or damaged.

Portions of the network(s) 27 may be wired or wireless. In someembodiments, a wireless interface between user-devices and the network27 may be preferred, since the wireless connection may be establishedand maintained more automatically and with minimal user efforts.

Most users may typically utilize many different players at differentlocations throughout the day and from day-to-day such as in differentrooms of the home, at different homes, at different work locations, indifferent automobiles, or various portable user-devices. In addition,there are many user-devices that the user may only temporarily use, suchas user-devices located at a hotel, a rental home, a rental car, on loanfrom a friend, etc. It is desired that the user's history and profile beinteroperable and automatically synchronized between all theseuser-devices so the user history collected at each user-device isavailable to all other user-devices. An experience-provider 26 mayautomatically perform the required level of synchronization between allof the user-devices and storage locations on the network(s).

In one embodiment, the user history and user profile information isstored redundantly at multiple locations distributed across anetwork(s), such as the internet, so that the user's information has ahigh availability (even if some network nodes/paths are down) and isrobustly protected from loss. Periodic back-up or archiving of theinformation may also be utilized to provide an additional protectionagainst loss of the user's information. In one embodiment, this storagefunction is provided by the experience-provider. Alternatively, aseparate storage provider may provide storage, backup, archiving andprotection of the user's history and library on the network. In-order toprotect user privacy, user information stored on the network may bestored in an encrypted form for which the storage provider does not holdthe decryption keys. Encryption mechanisms may be utilized to keep auser's history private and not accessible to human prying.

In some embodiments, there may also be one or more identity-providers29. An identity-provider 29 may be optionally used to provide ananonymous ownership of usage-rights so that the actual owner of acomposition remains hidden and is protected against disclosure toothers. In some embodiments, the identity-provider 29 may also performbanking functions in-order to maintain user anonymity and to protect theactual user's identity from disclosure to others.

Experience-Providers:

An experience-provider 26 is responsible for providing the adaptivepersonalized music (or entertainment) program that is customized foreach user and is integrated with the user's collection of compositions.The experience-provider 26 may coordinate the following functionsautomatically without requiring any significant user action:

-   -   Provide a sequence of compositions, highlights and other        material that is customized for each user based upon the prior        history of user control actions and feedback.    -   Provide copies of compositions, highlights and other material to        all user-devices as needed.    -   Manage, store, backup and make available the user's collection        so that it is available to all the user-devices. The user's        collection may be represented by a set of user usage-rights        tokens.    -   Manage, store, backup and update the user's history (including        control actions, feedback, play history, profile) across all of        the user-devices in-order to adapt to the user's changing        tastes.    -   Recommend new compositions and highlights likely to be appealing        to each specific user. Automatically incorporate the new        compositions and highlights into the user's program sequence and        the user's collection.    -   Provide pre-customized channels for each user (representing        different categories, genre or moods of music) that may then be        further optimized for each user based on user control actions        and feedback.    -   Provide additional advertisements, news, or weather        presentations in the user's program stream that are customized        for each user based on user control actions, feedback or user        profile.    -   Provide software updates for user-devices.    -   Obtain usage-rights for compositions that are made available to        the user. Pay royalties to composition owners based on the        user's usage.    -   Bill users for composition purchases, usage and other services.    -   Provide a “capture” mode capability to enable user's to identify        and later experience and evaluate a composition they may be        hearing from a non-user-device.    -   Provide a “share” mode capability to enable a user to share a        list of compositions with other users.

Although all of the above functions may be performed by the user'sexperience-provider, they may be performed by separate entities that areunder the coordination of the user's experience-provider. In oneembodiment, the user may have many experience-providers to choosebetween and may be able to easily (instantaneously) switch, with low/noswitching costs from one experience-provider 26 to another.

In one embodiment, the user's collection may be easily shared andutilized with all experience-providers 26 and all user-devices 22. Thismay be accomplished with user usage-rights tokens that are issued byusage-right authorities 24 or composition-providers 23 that areuniversally recognized by all experience-providers 26. This eliminatesproblems with tokens issued by each experience-provider 26 but which arenot recognized by other experience-providers and hence are nottransferable and not interoperable.

In some embodiments, an industry standard for universally recognizedusage-rights may be adopted that is available for use by all industryparticipants. Experience-providers may automatically translate auniversal usage-right of an individual user into an experience-providersproprietary usage-right that is compatible with the proprietary digitalrights management (DRM) system(s) used by the experience-provider. Forexample, a universal usage-right may be automatically translated into ausage-right which is compatible with the proprietary digital rightsmanagement (DRM) system used by the Apple iTunes/iPod systems. In thisway, a user no longer needs to be concerned that their purchases ofusage-rights for a composition will only be usable with a singlevendor's proprietary system (such as only Apple iTunes/iPod). Byeliminating this user concern, users may be more comfortable and hencemore likely/willing to increase their purchases of usage-rights forcompositions since their usage-rights are no longer being locked to asingle vendor. Universal usage-rights may also reduces the pressure onthe industry to provide compositions without DRM protections (e.g., innon-DRM protected formats). Hence, universal usage-rights may enable theindustry to continue to use DRM to protect against piracy, while stillenabling users to use their purchases of compositions (usage-rights) atall user-devices and with all experience-providers.

The experience-provider's costs for the library storage and managementfunctions may be effectively amortized across a large number of users.All transfers of information between the experience-providers repository(or depository) and the user-devices may occur automatically withoutrequiring any user knowledge or action. Concurrency of user data in thecurrently active user-device(s) 22 and the usage-rights repository 24may occur automatically across the network 27 without the user needingto be aware of it or taking any action.

Prior to a user-device 22 shutting down, all the latest user feedbackand user history may be forwarded to the usage-rights repository 25 forlater use by other user-devices. The user-device's user display mayoptionally include an indicator that is activated during user-device 22shutdown, to indicate whether concurrency with the repository has beencompleted. Optionally, the user-device 22 may include an automaticcapability of periodically trying to establish a network 27 connectionfor upload in-order to complete concurrency with the repository prior toconcluding shutdown.

In some embodiments, user-devices will be able to operate withintermittent or temporarily unavailable network 27 connections. When anetwork connection is not available, the user-device 22 may utilizecompositions and highlights that were previously transferred to thelocal storage in the user-device. New highlights and new compositionsmay be temporarily limited to what was locally stored during previousnetwork connections. In addition, timely information such as news andweather may not be available when the network connection is lost.

News, weather, traffic, etc may also be customized for the user basedupon factors such as the day of week, time of day, or the location ofuser. Customization of weather and traffic reports to the day of weekand time of day. Reports may be automatically adapted to the currentphysical location of the user.

Since the entertainment-program is customized for each user, in someembodiments, only one entertainment-program may need to be active foreach user at any one time. In some other embodiments, the user may wantthe same entertainment-program to be available at multiple locations,such as in multiple rooms in a house. The experience-provider 26 mayimpose limitations on the number of simultaneously active user-devicesand/or the maximum physical separation of user-devices that may besimultaneously active.

User-Device:

FIG. 3 is a functional diagram of a user-device 22 for generating anadaptable personalized entertainment experience. The user-device 22includes a “user control interface” 32 a for accepting user controlactions. The user-device 22 may include one or more means fordetermining the individual user that is active at the user-device. Theuser-device 22 may include a “user display” 32 b for presenting visualinformation for the current composition or user-device 22 status. Theuser-device 22 also includes “sound generation” capabilities 32 c or aninterface to an external sound generation apparatus so the user may hearthe customized sequence of compositions and other program information.The user-device 22 includes storage (e.g., memory) 33 to holdinformation locally that may include: 1) Compositions. 2) Newrecommendations list(s). 3) New compositions and highlights. 4)Usage-rights (tokens). 5) Advertisements, news and/or weather. 6) Userhistory 7) user-device software and updates. The memory storage 33 mayutilize non-volatile memory or media so the contents are maintained evenwhen the user-device is un-powered.

The “network interface” 31 receives information 34 from theexperience-provider 26 and sends information 35 to theexperience-provider. Most transfers to and from the experience-provider26 occur automatically without requiring the user to specificallyinitiate them. Information received 34 may include: 1) Favoritecompositions. 2) New recommendations list(s). 3) New compositions andhighlights. 4) Usage-rights tokens. 5) Ads, news and weather. 6) Userhistory. 7) Software updates. 8) User feedback validation. Informationsent 35 to the experience-provider 26 may include the user's history andupdates to the user's history. User history and updates to user historymay include: 1) User profile information. 2) User control actions. 3)User feedback. 4) User playback history. 5) User content restrictions.

The user-device 22 also includes a processor 30. The processor performsthe user functions such as 1) Sequence Generation. 2) User controlaction (feedback) capture. 3) User history capture and update. 4)Experience-provider 26 interface transfers.

Identifying the Specific User:

Each user-device 22 may determine the specific user that is active atthe user-device. Identification of the user at the user-device 22allows 1) using the user's usage-rights at the user-device; 2)customization of the entertainment program for the individual user; andany other user specific capabilities.

In one embodiment, each time the user-device 22 is re-started orpowered-up the user may be re-determined so that multiple users mayintermittently share the same user-device, yet experience a customizedprogram. Voice recognition of the user's voice or a unique verbalidentifier or some combination of both may be used. Other possibilitiesinclude the recognition of the user via a camera image taken at startup,or various bio-metric sensing of the user such as a fingerprint sensoron the “on” control or other user-device controls.

The user-device 22 may also keep a secured/encrypted record of thelogin-info of prior user-device users that were previously validated bythe experience-provider. This enables a prior user to login and utilizea user-device 22 when a network connection to the experience-provider 26is (temporarily) unavailable. In some embodiments, the user-device 22may need to periodically re-connect with an experience-provider,in-order to re-authorize another time-period for using the user-device22 without a network connection to an experience-provider.

In some cases, the identification process may be defaulted or biasedtoward the most recent user(s). For user-devices that are typically usedby only a single user, the user identity may be configured on initialuse and not reconfigured unless a reconfiguration is specificallyrequested by the user. In one embodiment, the user identificationprocess may require minimal or no special user actions.

Accuracy in identification of the user is important to preventcorruption of both the user's usage-rights and user history due to useridentity errors, piracy or identity theft. Additionally, since theuser's history and usage-rights are of considerable value to each user,user “identity theft” should be protected against. Methods for identityrecovery may be employed, so a user's history may be restored to thestate just prior to the occurrence of an identity theft. Software may beutilized by the experience-providers to monitor for unusual behaviorsthat are indicative of identity theft.

It is desirable to create a user experience so that it is in the user'sinterest to correctly identify them selves to the “system” and toprotect themselves against identity theft or the loaning of theiridentity to others. Users will realize that the use of their identity byothers, will corrupt their user feedback history and compromise theircustomized program experience. By protecting the user's collection andby providing a customized experience and continually introducing newcompositions that are of high value to the user, users will be naturallycompelled to correctly identify themselves and avoid loaning theiridentity to others.

Besides the everyday-userID (e.g., login-ID) used at the user-devices, amore hidden and secured user identity (e.g., anonymous-ownerID) may bemaintained by the “system”. This allows the user to re-establish a neweveryday-userID if it becomes compromised.

User Interface:

The user-device 22 (i.e., personalized player) may be controlled by theuser via numerous types of user interfaces including voice activated,manual controls, touch screens, interactive displays, remote controldevices, and/or any other type of interactive and/or Human MachineInterface (HMI).

FIG. 4 shows an example of a manual user interface for use where theuser is within reach of the controls such as with a portable player, aremote control, or a user-device 22 located in an automobile withinreach of the driver. Such controls may be implemented withelectrical-mechanical controls such as push buttons, switches, slidersand knobs or with interactive touch screen control. In anotherembodiment, the controls of FIG. 4 may also be accomplished with voicecommands.

The “Favorites-New” slider 41 is used to vary the percentage of newcompositions that the user will hear. When the slider is at the“favorites” position (lowermost position) all compositions are selectedamong those most highly liked by the user. When the slider is positionedat the “new” position (uppermost position) the user is only exposed tonew compositions he or she is not familiar with. The user may adjust the“Favorites-New” slider position by activating (pressing) the “New” 42 aand “Favorites” 42 b controls or in an alternative embodiment bydragging the slider indicator 41 upward or downward. As the slider 41 ispositioned further away from “favorites” and closer to “new”, the userwill hear a greater percentage of new compositions and a lowerpercentage of favorites.

In another variation, highlights may be inserted at increasing frequencyas the position of the “Favorites-New” slider is closer to the “new”position.

As shown in FIG. 4, the user-device 22 may include a display 40 toindicate information about the selected channel, composition beingplayed (artist, title, etc), playtime, user-device status, etc. Theuser-device 22 may also include typical user controls such as “pause” 42e, “play” 42 d, “forward” (or “skip”) 42 c, “back” 42 f, and channelcontrols (43 a, 43 b, 43 c and 43 d).

In another optional enhancement, when a sequence of user commandsindicate user difficulty or frustration, the user-device 22 may issuerecommendations to the user on how to better utilize the user-device'scapabilities. Such recommendations might be issued by voice synthesis oron the user-device display.

User Usage-Rights:

Rather than ownership of physical media, a user's collection may bedefined by a set of tokens that define the usage-rights owned by onespecific user or a specific set of users (e.g., a family). Ausage-rights token may hold the usage-rights for a digital-work (e.g., acomposition) for a specific individual user (or set of users) for aspecific composition. Since the tokens are electronic, the usage-rightstokens may be easily shared or distributed to all user-devices that thespecific user owns and/or uses. This allows the user's collection to beautomatically available anywhere the user is located. In anotherembodiment, a usage-rights token may control a user's usage-rights for agroup of compositions (e.g., all the compositions on an artist's album).

Over time, a user may purchase various usage-rights to particularcompositions to form their collection.

The usage-rights may extend for any period of time (start/stop time) orfor the user's lifetime or perhaps perpetual rights that may betransferred to another user. The usage-rights may be limited to acertain number of plays or may be for an unlimited number of plays. Theusage-rights may be limited to certain format(s) or may be valid for allformats available. The usage-rights may also extend to future formatsthat may become available due to technology advancement. Theusage-rights tokens may be upgradeable, when desired by the user, toexpanded usage-rights. In some embodiments, the tokens may berecognizable by all user-devices. Explicit and/or implicit action(s) bythe user may initiate the purchase or acquisition of tokensautomatically on the user's behalf. Tokens may be automaticallypurchased or acquired on behalf of the user and added to a user'scollection (of usage-rights and/or tokens).

The usage-rights token may be separate from the composition. As shown inFIG. 12, the compositions may be delivered and stored in an encryptedform 124 at the user-device 22. The usage-rights token 122 along withuser ID/password/biometric information 120 c, date/time 120 b and “userfeedback validation” information 120 a may be used by the user-device 22to decrypt the composition key. The composition key 127 may then be usedby the user-device 22 to decrypt the composition 125 to generate thedecrypted composition 126 for playback to the user. In some embodiments,reduced-capacity usage-rights tokens rather than the full usage-rightsmay be delivered to user-devices 22.

The “user feedback validation” 120 a may be encrypted and represent avalidation that the user has provided regular and consistent usage andhistory feedback to the experience-provider(s). If appropriate userfeedback is not received from a user-device, the “user feedbackvalidation” 120 a may lockout usage of that user-device until suchexpected feedback is re-established. The “user feedback validation” 120a may also include (a secured) date and time information to protectagainst improper settings of the local clock by a user in-order tocircumvent a token expiration date. The “feedback validation” 120 a mayalso be used to inhibit user ID piracy or inhibit multiple users fromusing a single user's login-info (e.g., login-ID) by preventing anexcessive number of user-devices from being simultaneously operated inwidely different physical locations.

In one particular embodiment, users may easily switch betweenexperience-providers 26; and a user's usage-rights tokens may berecognized and usable with all experience-providers 26 and user-devices.The usage-rights authorities 24 and/or composition-providers 23 areresponsible for imposing a “standard for usage-rights tokens” 25 so theusage-rights may used by all experience-providers and user-devices. Theusage-rights tokens may be issued by usage-rights authorities 24 orcomposition-providers 23 that are independent of but recognized by allexperience-providers. In some embodiments, a composition andcorresponding usage-rights provided to a user-device by oneexperience-provider; may be utilized at the user-device by any other(authorized) experience-provider.

The usage-rights authority 24 or composition-providers 23 may obtain anauthorization from the owners of each composition, in-order to issueand/or sell usage-rights to users. A secure database of all issuedtokens may be maintained in the usage-rights repository. The tokens maybe distributed for use at any or all the user-devices and with allexperience-providers. To eliminate user concerns about the loss of theirtokens (representing their collection), a user's complete collection oftokens may be recovered by accessing the usage-rights repository tokendatabase. The user's collection of tokens may be robustly preservedagainst loss by distributing multiple copies at different physicallocations across a world-wide network and periodically backed-up andarchived on the network. In this manner, a user's collection may berobustly preserved no matter what happens to a user-devices or storagedevices. In one embodiment, the user's tokens may be automaticallypreserved by a usage-rights authority, an experience-provider 26 and/ora storage provider without requiring user efforts.

The individual user's collection of compositions may be represented by acollection of usage-right tokens. In some embodiments, the managementand handling of the tokens occurs automatically for the user-devices anddoes not require user action or knowledge.

In some embodiments, a copy of a token may be issued to users in aphysical hardcopy form or in an electronic form. For example, a receiptrepresenting a token ownership may be issued at the time of purchase.For privacy and security reasons, the format and contents of ausage-rights token issued to the owner may be different from tokensmaintained on the network. In one embodiment, a token issued to an ownermay be validate-able and convertible into an electronic token that maybe used on the network. In some embodiments, issuing tokens to users maynot be desirable, because the user becomes involved with the storage andmanagement of such owner issued tokens and they are redundant to thetokens automatically maintained by the usage-rights repository 24.

In one embodiment, users may be allowed to exchange their previouslypurchased physical media such as a CD for usage-rights token(s). In oneembodiment, previously used proprietary usage-rights (e.g., AppleiTunes) may be converted (perhaps for a conversion fee) into generalizedusage-rights that may be usable with all vendors user-devices. Theproprietary usage-rights may be then revoked or disabled in theproprietary user-device(s) via the revoke capabilities typicallyincluded within each vendor's proprietary DRM approach. The convertedgeneralized usage-rights are then added to the usage-rights repositoryso they may be used for user-devices from all vendors and with allexperience-providers.

The token ownership may also be optionally transferable to another userso a user may transfer a portion (or all) of their collection to anotherindividual (e.g., upon the owner's death). In some embodiments, anominal fee may be charged to transfer a token or a set of tokens toanother ownership. To control piracy from extremely short-termexchanges, a limitation on the minimum time between such transfers maybe imposed.

Usage-Rights Representations:

In one embodiment, the token may represent a receipt of ownership orallowable usage that may be understood and validated by anyexperience-provider 26.

The token may represent the user's ownership and/or usage-rights of anytype of digital-work including music, music videos, multi-media,artwork, pictures, images, audio, sound, short films, movies, videoclips, television programs, audio versions of books, a visual book,talks, speeches, voice content, lectures, software program, softwareplug-ins and any other type of digital-work.

In some embodiments, the token may be defined to be valid for allavailable (network interface-able) user-devices and their correspondingformats. This is a major convenience for user's since they no longerneed to be concerned with the details of user-device formats, formattranslations and compatibility problems. The user is guaranteed thattheir token will be good for use with all their user-devices.

In other embodiments, the token may only be valid for a specified subsetof user-devices and their corresponding formats (e.g., only Apple deviceformats). In other embodiments, tokens that are limited to only certainuser-devices may be extensible so that they may be upgraded, possiblyfor a small fee, to be compatible with a wider set of user-devices orall user-devices.

Composition-Providers may decide to issue free tokens that allow alimited use of a composition (e.g., limited number of playbacks oruse-time) in-order to interest a user in ultimately purchasing thecomposition. The offer of a free token may be based on indicators ofcustomer reputation such as the user's (anonymous) credit rating, thequantity of prior user purchases and the user's payment history.Experience-providers, using projected estimates of a user's interest,may request such free tokens for specific compositions from acomposition-provider 23 on a user's behalf.

For music, the token may represent usage-rights for only a specificversion of a song by a specific artist (for example, the original studiorecording).

In one embodiment, the token may be valid for all available digitalformats (e.g., CD-format, MP3-format, etc), including different formatsrequired by different user-devices and different quality formats. Forexample, the token may be valid for a cell-phone format that may have aninherently lower bandwidth/quality, a MP3 format and for an ultraquality user-device (such as Super Audio CD format) requiring greaterstorage and bandwidth (as well as all intermediate quality formats).

Tokens may also be used to represent usage-rights for compositionhighlights, for example a shorter version of the composition thatcontains especially compelling portions of a composition. There may bemultiple highlight versions of different quality and format. Acomposition-provider 23 may issue for free to a certain user, a tokenthat allows a certain number of plays of a composition highlight,in-order to generate user interest in eventually purchasing ofusage-rights for the composition at some later time.

In the case of a book, the usage-rights may allow the book text andimages to be by viewed on any user-device. For example, the data formatfor a mobile phone may be different from that for a PC or a tabletbook-reading user-device. Their usage-right token may be valid for useon a mobile phone, a specialized book reader, a personal computer andany other user-devices. The experience-provider 26 may automaticallydeliver the appropriate format to whatever user-device 22 the usercurrently wants to view the book with. For a book, the free token may belimited to a certain amount of time or limited to only certain portionsof the book in-order to allow a user to preview the book before decidingwhether to purchase it.

Capturing and Utilizing User Control Actions:

The user's control actions (control history) from a user's varioususer-devices may be captured as user feedback about the compositionsheard by the user. The user control history (feedback history) may thenbe utilized as input for the ranking of compositions by likeability andfor the creation of a customized composition sequence (or entertainmentprogram) for each individual user.

User feedback about each composition when it is playing may be obtainedbased on the user's usage of the “back” 42 f and “forward” 42 c (“skip”)controls (or the equivalent voice controls). For example, a user'scomposition rating may be increased, whenever the user uses the “back”42 f control (or a series of “back” controls) to request that a recentlyplayed composition be repeated. For example, if the user uses the “back”control to immediately request that the currently playing composition berepeated, the user rating for that composition is significantlyincreased. Similarly, if the user uses a series of “back” controls torequest that a recently played composition be replayed, then the userrating of the requested composition is significantly increased. If theuser requests that a composition be played after searching for thecomposition in the user's favorites list, the user rating for thatcomposition may be increased. If the user requests that a specificcomposition be played, the user rating for that composition may beincreased.

Similarly, a user's composition rating is decreased, whenever the useruses the “forward” control 42 c to request that the rest of a currentlyplaying composition is to be skipped. The amount the user's compositionrating is decreased may be dependent on how much of the composition hasplayed before the user activates (presses) the “forward” control. Forexample, the rating may be decreased a smaller amount if the user skipsforward near the end of a composition playback. The rating may bedecreased a larger amount if the user skips “forward” near the beginningof the composition playback.

A user's composition rating may be changed by the “forward” or “back”controls, only when the composition has played for a long enough timefor the user to recognize it (i.e., the playback time has exceeded arecognition threshold time). For example, if the user hits the “back” or“forward” control so quickly in a sequence that there is not enough timefor the intermediate compositions to start playing and be heard by theuser, then the ratings of the intermediately bypassed compositions maynot be affected.

An additional method for indicating positive user feedback may beaccomplished by a single action by the user, such as activating a singlecontrol (if manually controlled) or the speaking a single word (if voicecontrolled). For a user-device 22 (e.g., player) with manual controlssuch as in FIG. 4, a single control switch called “Like” 42 g (oranother suitable name) may be pressed by the user while a composition isplaying in-order to indicate a desire that the composition be playedmore frequently. Optionally, different amounts of “like” may beindicated by the number of times the user activates (presses) the “Like”control 42 g while the composition is playing. For example, if the useractivates (presses) the “Like” control multiple times while acomposition is playing, the user rating for that composition (and thefrequency that the composition is played) would be significantlyincreased. Alternatively, the “Play” control 42 d may be used (insteadof the separate “Like” control) to indicate a user desire for thecurrently playing composition to be played more frequently. The user mayactivate the “Play” control one or more times to indicate a desire tohear the currently playing composition more frequently. Thevariation/distribution in the number of multiple “Like” pushes typicalfor a given user may be used to calibrate the appropriate adjustment ofthe user's composition rating versus number of “Like” pushes. Suchcalibrations may be adjusted over time so that the rating changeassociated with each different number of “Like” pushes, may adapt toeach user over time.

Similarly, a compositions rating may be increased when a composition“highlight” segment is playing and the user hits the “Play” control 42d, in-order to immediately hear the full composition.

Although, a “dislike” control (or voice command) may be similarlyutilized to indicate a negative feedback, in some embodiments, it maynot be needed since use of the “forward” (skip) control while acomposition is playing, is itself a sufficient indicator of “dislike”.

Even if the user does not provide any feedback on a composition during aplayback, the user's rating may be automatically adjusted lower (orhigher) based on an estimated change in likeability as a function of thenumber of times heard by the user. FIG. 7 a show examples of likeabilityof a composition as a function of “number of times heard”. The dataillustrated by these curves may be generated based upon the aggregatefeedback to the composition from other users considered similar to theuser. Curve J in FIG. 7 a, is an example of a high initial likeabilityfor many playbacks followed by an eventual decline in likeability. CurveK in FIG. 7 a, is an example of medium high initial likeability followedby an initial increase in likeability with times played, then followedby an eventual decline in likeability from the peak likeability.Although curves are shown for illustration purposes, the actualembodiment, may utilize look-up tables, databases, functions, equations,formulas; etc.

If the user has had a lot of recent forwards (skips) over prior favoritecompositions, the favorites-new setting 41 may be automatically adjustedmore towards the “new” mode so that the user is exposed to a largernumber of new compositions. In this case, the favorites-new indicator(41 in FIG. 4) may be automatically adjusted to be closer to the “new”position.

By utilizing the normal user control actions as feedback on eachcurrently playing composition, the users rating may automatically adaptto the user's evolving preferences and tastes over time withoutrequiring special actions by the user to specifically rate compositions.A user's composition rating may be re-adjusted each time a compositionis played or selected, so the rating adapts gradually and automatically.User feedback on each composition while it is playing occursautomatically based on the user's normal control actions.

In some embodiments, the user does not need to know the artist, title oranything else about the composition; only whether he or she likes whatis currently playing. The user does not need to take special action torate compositions on a rating scale. The user also does not need to beaware of a rating number system (e.g., 1 to 100) or adjusting therelative number rating of one composition versus another and to manuallyre-adjust such ratings as the user's tastes change over time. The useris not required to navigate a set of windows or menus to rate thecomposition. The user is not required to manually select from a catalogof compositions in-order to create composition playlist(s).

FIG. 1 illustrates the capture of user control actions representing userfeedback about a currently playing composition. “Start” 4 occurs withthe “Begin composition Play” and the “Reset and start of the playbacktimer” 7. The playback timer records how long each composition has beenplaying. When the user control action (while the composition is playing)is a “Forward” pressed to skip” 3 d (i.e., stop currently playingcomposition and go to next one), the timer may be used to determine thepercentage of the composition that was played, which may berepresentative of the amount of user dislike for the composition (anegative feedback). Typically, the lower the percentage that acomposition was played through, the greater the user dislike for thecomposition. When the user control action is a “Back” pressed to repeat”3 c (while the composition is playing or has just finished), an“Immediate repeat request” (a positive feedback) is generated for thecomposition. When the user control action is a “Like” pressed duringplay” 3 b, the number of times the “Like” was pressed during compositionplayback (a positive feedback) is captured for the composition. If theuser took specific action(s) to play the composition, such as “Userrequested composition to play” 3 a (a positive feedback), the mannerthat the user requested play is captured. For example, the user may havesearched his favorites to request that the specific composition beplayed. When a complete playback has occurred 3 e, a “100% played” maybe captured as user feedback.

In some embodiments, the user-device(s) may have a “play more often” or“play more frequently” button/control, instead/in-place of a “like”button/control. The user may then activate this button to indicate tothe system that they want to experience the composition more frequentlythen the system has been providing the composition. The number of timesthe presses/activates the “play more often” or “play more frequently”button/control may allow the user to indicate the amount of additionalfrequency that the user desires. For example, pressing the button oncemay indicate a desire to experience the composition twice as often.While pressing the button twice might indicate a desire to experiencethe composition three (or four) times as often.

Note that the composition playback may be required to have played for atleast a “Recognition Time” threshold 6 before certain user controlactions are captured. The “Recognition Time” threshold represents theminimum amount of time that a composition must played in-order for auser to hear it and form an opinion. The threshold may be used to filterout user control actions that occur too soon after a composition startsplaying, to be true feedback about the composition. When a compositionplayback begins, the composition ID, date and time may also be captured.Note that there are many “user control actions during compositionplayback” 2 that may generate “User Feedback” 1. The “User Feedback” 1is then “added to the User History” 7.

User Actions:

User actions may be divided into three general types:

-   -   User directly inputs their preference for a composition.    -   Control actions that imply a user's preference for a        composition.    -   Detecting implicit user re-actions to a composition.

Each of these types of user actions, are discussed in more detail insections that follow.

User directly inputs their preference for a composition:

In this case, the user manually inputs their preference for acomposition. For example, the user may press a “thumbs-up” orthumbs-down” button to directly input their preference for acomposition. Or, the user may select/input a rating for a composition ona rating scale (e.g., 3.5 stars out of 5 stars) to manually indicatetheir current preference for a composition. The user input theirpreference while viewing an interactive display and/or experiencing thecomposition. A major problem is that the user must be bothered (take thetime) to manually input their preference for each composition (100's or1000's). In addition, the user must manually change or update theirpreferences as their tastes change over time. Manual inputting apreference may be a significant interruption and inconvenience for theuser.

Examples of a user directly inputting the preference for a compositioninclude:

-   -   User presses a “thumbs-up” button.    -   User may presses “thumbs-down” button.    -   User activates a “like” button/indicator while composition is        playing.    -   User activates/presses “dislike” (thumbs-down) button/control        while composition is playing.    -   User presses a “play more frequently” button (one or more times)        while a composition is playing.    -   User selects on an interactive display the number of stars        (e.g., 3.5 stars out of 5 stars) to indicate their preference.    -   User inputs/selects on an interactive display their preference        on a 0 to 100 point scale (input a value of 85).

Control actions that imply a user's preference for a composition:

Examples of actions by a user that may indicate a likeable preferencefor a composition include:

-   -   User searches to find composition and then requests composition        to be played and does not forward-past during its playback.    -   User requests that composition be played and does not        forward-past during its playback.    -   User requests/views visual information about composition while        it is playing.    -   User activates “back” control to replay composition (within 0 to        3 seconds after composition finished playing).    -   User activates “back” control to replay composition (within 3 to        15 seconds after composition finished playing).    -   User activates “back” control to replay composition (more than        15 seconds after composition finished playing).    -   User activates “back” control multiple times (back multiple        compositions) to replay composition    -   User activates “scan backward” control to re-play a portion of        composition.    -   User requests that full composition be played while highlight        (sample) of composition is playing or has recently finished.    -   User recommends the composition to another user(s).    -   User increases sound volume during playback.    -   User requests the “identification” of a composition originating        external to the user's user-device.    -   User requests the “identification” and shows interest in a        composition originating external to the user's user-device.    -   User requests the “identification” of a composition originating        external to the user's user-device and adds to the user's        collection of compositions.    -   User requests the “identification” of a composition originating        external to the user's user-device and purchases composition.

Examples of actions by a user that may indicate a user's dislike for acomposition include:

-   -   User “forwards past” (skips-past) composition within 2 seconds        of experiencing composition.    -   User “forwards past” composition within 2 to 5 seconds of        experiencing composition.    -   User “forwards past” composition within 5 to 15 seconds of        experiencing composition.    -   User “forwards past” composition within 15 seconds to beginning        20% of experiencing composition.    -   User “forwards past” composition within the beginning 20% to 40%        of experiencing composition.    -   User “forwards past” composition within the beginning 40% to 70%        of experiencing composition.    -   User “forwards past” composition within the beginning 70% to 90%        of experiencing composition.    -   User “forwards past” composition during last 10% of composition.    -   User “forwards past” (skips-past) composition within 2 seconds        of experiencing highlight (sample) of composition.    -   User “forwards past” composition within 2 to 5 seconds of        experiencing highlight (sample) of composition.    -   User “forwards past” composition within 5 to 15 seconds of        experiencing highlight (sample) of composition.    -   User “forwards past” composition within 15 to 30 seconds of        experiencing highlight (sample) of composition.    -   User “forwards past” composition after more than 30 of        experiencing highlight (sample) of composition.

These control actions by a user may be used to determine/influence therating/preference of a user for a composition and/or the “time betweenplaybacks” of the composition.

Detecting implicit user re-actions to a composition:

Sensors may be located in the environment around a user or sensors maybe worn by a user to implicitly detect a user's re-action(s) to acomposition. For example, sensors may be embedded in user devices; wornby the user; or embedded in the user's clothing. The responses detectedby these sensors may be analyzed and to determine how a user isresponding to a composition. As with other user action(s), theseimplicit actions by a user may also be used to determine/influence therating of a composition and/or the “time between playbacks” of thecomposition.

For example, a microphone (or other sound sensor) may be in the user'senvironment; in user-device(s); and/or worn by a user. For example,microphone 47 in a user-device (FIG. 4) may be used to capture the soundof a user singing along with a composition which may be a “like”indicator of user for that composition.

For example, a camera in the user environment; in a user-device(s); orworn by the user may monitor the user's facial expressions and/or theuser's eye pupil dilation; in-order to determine the user's reaction toa composition (e.g., frowning; smiling; etc). Or the camera may detectdancing by a user.

Additionally, micro-miniature (e.g., semiconductor) accelerometers,gyroscopes; inertial measurement units; magnetic field sensors may beused to detect user orientation and user actions.

Additionally, sensors (pulse detectors; skin conductivity;electromyography; etc) may be body-worn and/or embedded in the clothingof the user to also detect changes to the inner body functionalityand/or internal state of a user.

Some examples of implicit user actions (in response to a composition)include:

-   -   User “sings along” with more than 10% of composition.    -   User “sings along” with more than 20% of composition.    -   User “sings along” with more than 40% of composition.    -   User “sings along” with more than 60% of composition.    -   User “sings along” with more than 80% of composition.    -   Change in user's facial expression (e.g., smiling; looking        happy; etc).    -   Change in user's facial expression (frowning; etc).    -   Dancing or other movement in response to the composition.    -   Change in user's pulse.    -   Change in user's heart (electrocardiography).    -   Change in user's breathing.    -   Change in user's breathing rate.    -   Change in user's galvanic skin response (skin conductivity).    -   Change in user's muscle activity (electromyography)    -   Change in user's muscular tensions.    -   Change in user's eye pupil dilation.

Identifying other users that may be “similar” to a user:

There are many different methods of identifying other users that are“similar” to a user.

Other users that are “similar” to a user may be identified by using theaggregate “likeability” mapping analysis; to identify other users thatlike the same compositions as the user. Examples of aggregatelikeability mapping and likeability indexes are shown in FIGS. 9 and 10,and are described elsewhere in this specification (and its parentspecifications).

Alternatively, in some embodiments, other users that are demographically(age; sex; education; location; ethnicity; etc) “similar” to a user maybe determined by using the prior history/feedback of the user and otherusers. As an example, other users that are similar to a user may bedetermined using the methods disclosed in U.S. Pat.No. 7,146,329(Conkwright, et al), which is incorporated herein by reference.

Alternatively, in some embodiments, other users that have interests(e.g., like certain genre/categories; artists; etc) that are “similar”to a user may be determined by using the prior history/feedback of theuser and other users. As an example, the interests of a user may bedetermined using the methods disclosed in U.S. Pat. No. 5,732,216(Logan, et al), which is incorporated herein by reference.

Rating/preference of a user for a composition:

For each individual user, a unique rating/preference may be associatedwith each composition.

Depending on the embodiment (or situation/case), the user's rating orpreference for a given composition: may be manually input/entered by theuser, and/or may be automatically determined (e.g., calculated) for theuser by monitoring user actions (i.e., control actions by the user orimplicit re-actions of the user).

In some embodiments, it may be preferred that only automaticallydetermined (e.g., calculated) ratings/preferences may be used, so thatthe user will not have to manually enter any ratings for compositions.

Depending on the embodiment, if a manually and a calculatedrating/preference are both available, then one of these may bepredefined to be automatically used to determine the time betweenplaybacks of a given composition. In some embodiments, if theautomatically determined (e.g., calculated) rating/preference is basedupon a least a defined minimum number control action events, then thatvalue for the rating/preference may be assumed to be valid and is used.

Determining a rating/preference of a user for a composition, by usinguser actions:

Depending on the embodiment, the values of the rating/preference may beexpressed in integers (e.g., 0 though 100) or as decimal numbers (e.g.,a rating of 45.2). As known by those skilled in the art, there are manyscales that may be used to reflect the magnitude of a rating/preferenceof a user including a number of stars (e.g., 0 stars to 5 stars) andfractions of stars (e.g., 2.25 stars). For purposes of illustratingconcepts in this specification, a scale of 0 to 100 is arbitrarily usedin portions of the discussions.

FIG. 22 shows a flow chart of one embodiment for automaticallydetermining the magnitude of the rating of a user for a specificcomposition by using actions by the user which are associated with thecomposition.

When there have not yet been any user control actions by a user for acomposition, an initial starting value may be determined/used. In someembodiments, a (common) default value (e.g., 50 on 100 point scale) maybe used for the starting value. In other embodiments, a unique initialstarting value may be determine/used for each composition for a user. Insome embodiments, the starting value may be determined by using theprior history/feedback of other users that are considered “similar” to auser. Methods of identifying “similar” users are described elsewhere inthis specification.

FIG. 22 element 2202 shows an example of calculate/determine an “initialstarting rating for the user” by using “info about other users” thatwere determined to be “similar” to the user”. In some embodiments, thecurrent value for the rating/preference for a specific composition forother users that are determined/considered to be “similar” to a user maybe averaged to establish an initial starting value for the user who hasnot yet experienced the composition. Alternatively, the value for therating/preference for a specific composition that other “similar” usershad when they initially experienced the composition (e.g., when they hada play-count of around 5 to 10) may be averaged to establish an initialstarting value for the user who has not yet experienced the composition.Alternatively, the peak value for the rating/preference for a specificcomposition for other “similar” users; may be averaged to establish aninitial starting value for the user who has not yet experienced thecomposition. Alternatively, a defined fraction (e.g., 80%) of the peakvalue for the rating/preference for a specific composition for other“similar” users; may be averaged to establish an initial starting valuefor the user who has not yet experienced the composition. Many othersimilar/equivalent methods may be used by those skilled in the art toestablish an initial starting rating for a user.

As shown in FIG. 22 element 2203, the rating of user for a compositionmay then be adjusted/updated; by processing all of the user actions thatare associated with the specific composition; in the order of theiroccurrence (where the first occurrence in time may be processed first).The prior value for the rating/preference may be adjusted higher orlower based upon a positive or negative adjustment value, which dependson each “action by the user”. FIGS. 24 a to 24 d show numerous examplesof “adjustment to the rating of a user for a composition” versusdifferent “actions by a user”. The examples in FIG. 24 a-24 d assumethat the rating/preference is a positive preference where the higher therating value the more the user prefers the composition. The examples inFIG. 24 a-24 d also assume that the rating is scaled into a range of 0(total dislike) to 100 (maximum like). As an example, as shown in FIG.24 a, if the “action by a user” was a “user request that composition beplayed” (an indication of user likeability for that composition) thenthe value of the rating/preference of that user for the compositionwould be increased by “+20”.

If an update/adjustment were to result in a rating/preference value togo outside/beyond the defined range (for example, 0 to 100) therating/preference may be clamped so it will not go outside the rangebeing used. For example, if a rating/preference from prior actions wasequal to 85 and a new control action by the user had an adjustment valueof +20, then the updated rating/preference will be limited/clamped to100 (and not 105) so it will remain inside the defined range.

As shown in FIG. 22, element 2204, when all the user actions for aspecific composition have been processed; then the most recent ratingfor that specific composition may be established and saved into memory2205.

Note that the prior values of the rating/preference of the user may besaved/stored in a memory 2205 (FIG. 22), so that an updated rating maybe determined by using the stored rating value and only needing toprocess the newer actions by the user that are not yet reflected(occurred later in time) than in the stored rating. The ratings may bestored in user-device(s) and/or in other memory/storage that isinterconnected and/or networked with the user-device(s).

In some embodiments, the rating for a composition is automaticallyupdated, each time after a composition has finished being played or whenthe user has taken new actions that are associated with the composition.This allows the new updated rating value to be used in the process ofdetermining when that composition will be scheduled to be played again(described elsewhere in this specification).

Note that if a complete history of user actions is saved/stored inmemory, then the rating may be re-calculated from scratch using a newalgorithm or relationships/parameters. This may allow user ratings to beimproved simply by processing the old/prior stored data with the newalgorithm(s).

In some embodiments, an approximate rating/preference of the user for acomposition may be determined/estimated by only using a limited number(“z”) of the last control actions by the user. For example, only thelast 6 or 10 (e.g., “z”=6 or 10) control actions by the user that areassociated with a particular composition, may be used to determine therating for the user for that composition.

Note that a user may make erroneous or unintended user actions (e.g.,control actions). In addition, the system may misinterpret the user'smeaning/intent of any single control action. Hence, it may be desirablethat the magnitude of the adjustment to a user rating for a compositionwill not be excessively adjusted by a single user action by itself.Therefore, in some embodiments, the amount of adjustment to a rating dueto new user action, may also depend on the extent that the newer useraction is consistent with previous user action(s) for that composition.That is if a newer control action is consistent with prior useraction(s) then the user's preference may be more confirmed, and hencethe magnitude of the adjustment may be increased/larger. Alternatively,if a newer control action is inconsistent with prior user action(s) thenthe user's preference may be less certain, and hence the magnitude ofthe adjustment may be reduced.

FIGS. 25 a shows an (optional) embodiment were the amount of adjustmentto a rating is dependent on the number of consistent or inconsistentthat previously occurred for a composition. Assume that “user action m”is a like indicator (e.g., indicates the user has a positivedesire-for/likes the composition). As shown in FIG. 25 a, greater thenumber of prior positive user actions then the more the rating isincreased/positively adjusted when user action “m” (like indicator)occurs. For example, if there were 3 prior positive user actions, thenthe rating adjustment for a newer ‘m” user action is +19, rather than+10 if there were no prior actions (e.g., the composition is “new” tothe user). Alternatively, if the 4 prior control actions were negativethen the adjustment is only +5 (rather than +10) when a user action “m”occurs.

FIG. 25 b shows another (optional) embodiment, where the amount ofadjustment for a user action depends on both the newer user action, aswell as what prior user action(s) occurred.

Determining a rating/preference of a user, by using a play-count:

In another different embodiment, a user's rating/preference for acomposition may be determined by using relationship(s) that define auser's preference (e.g., likeability) as a function of: the number oftimes the user has heard the composition (e.g., play-count) or thecumulative amount of time the user has heard the composition. In someembodiments, a unique relationship may be used for each composition orgroup of similar compositions. The number of times a composition hasbeen heard by the user may sometimes be referred to as “play-count” bythose skilled in the art.

FIG. 7 a show examples of the variation of the rating/preference(likeability) of a composition as a function of “number of times heard”(e.g., play-count). Curve J in FIG. 7 a, shows an example of a highinitial likeability for many playbacks, followed by an eventual declinein likeability, as the user becomes tired of the composition. Curve K inFIG. 7 a, is an example of medium-high initial likeability followed byan initial increase in likeability (as the user gains an appreciation ofthe composition) with times played, then followed by an eventual declinein likeability from the peak likeability, as the user becomes tired ofthe composition. Although curves are shown for illustration purposes,the actual embodiment, may utilize look-up tables, databases, functions,equations, formulas; etc.

The relationship(s) illustrated by these curves may be generated basedupon the aggregate feedback to the composition from other usersconsidered similar to the user. That is, users that are similar may havea similar variation in preference versus the play-count.

Note that a high value for a “play-count” (e.g., number of times played)by itself may not necessarily indicate that a user currently has a highlikeability for a composition. Alternatively, a song with a high“play-count” may still remain one of the user's current favorites andthe user still wants to hear it frequently. For example, a song with ahigh “play-count”, may have been heard so many times by the user thatthe user is tired of hearing that song and may not want to hear thatsong again. In this case, the user may have had a high preference forthe composition in the past (resulting in a high play-count) but may nowbe tired of the composition (e.g., current preference is low).

Hence, simply assuming that the high value of the play-count means thata user has a current high preference for that composition is flawed.This flawed assumption regarding the play-count is one of the problemswith the “Smart Playlists” systems of the Apple iTunes and U.S. Pat. No.6,941,324 (by Plastina). Another weakness of the Apple iTunesimplementation is that: the “play-count” may only increment after acomposition has finished playing completely and hence the Apple iTunes“play-count” parameter may not distinguish between user action to play aspecific song (a strong indicator of user interest) and a non-userinitiated playback of the song by a user playback device (a limitedindicator by itself).

Another possible weakness of using a “play-count” parameter is that notall user-devices may capture/collect/forward a play-count. This may becompensated for by user-device(s) that a user may carry/wear or are inthe user's environment, which can capture/identify/note compositionsthat the user is exposed to as the user goes about their daily life.

In some embodiments, it may be useful to carefully distinguish betweenseveral different “play-count” parameters such as: a) the number oftimes initiated; b) the number of times played completely; c) the numberof times played partially; d) the number of times initiated by useraction; e) the number of times initiated without user action due to ashuffle/random-playback mode) 0 the number of times initiated as part ofa playlist g) the number of times initiated by a customized (to theuser) music selector. Another alternative/additional parameter to “playcount” (with similar distinguishable cases) is the “cumulative playbacktime” that the specific composition has been heard by the user (i.e.,=sum of all the playback times for the user for that composition).

Determining the “time between playbacks” of a composition, by using arating/preference:

In some embodiments, a target or desired time between playbacks of acomposition may be based upon the magnitude/amount of the user's ratingand/or preference for that composition. In some embodiments, the “timebetween playbacks” of a given composition may be determined by usingrelationships(s) to user's rating/preference. In some embodiments, atarget/desired “time between playbacks” of a composition may beautomatically determined by using a relationship(s) where the “timebetween playbacks” varies with the magnitude/amount of the user'srating/preference for that composition.

FIGS. 7 c-7 i show examples of relationships where the “time betweenplaybacks” (“time between plays”) may vary based upon (e.g., as afunction of) the “rating or preference” of the user. As shown in some ofthe examples, in general, when the “user rating or preference” for aspecific composition is higher, then a shorter “time between playbacks”of that composition may be used, so that the user may experience thecomposition more frequently.

In some embodiments, a desired “maximum time between playbacks of acomposition may be based upon the amount of the user's rating/preferencefor that composition. For certain compositions that have a high user“rating or preference”, the user may want to hear these compositionsmore frequently, and hence it may be desirable to attempt to keep thetime between playbacks below/less than a “maximum time between plays”.

FIG. 7 e illustrates an example of how the “maximum time between plays”may vary based upon (e.g., as a function of) the “rating or preference”of the user. As shown in the example of FIG. 7 e, when the user “ratingor preference” exceeds a “high threshold”, then the “maximum timebetween plays” may be utilized by the system. In some embodiments, thisfeature may be used when the composition is “new” to the user and theusers “rating or preference” for the composition is high. Note that if auser is (often) manually requesting a composition (or a “new”composition” to be played at shorter time between playbacks then: 1) theuser rating or preference may be increased; and/or 2) the relationship[e.g., curve/function/etc] may be changed/adjusted to cause a reductionin the “maximum time between plays”. By continually making adjustmentsbased upon a user's control actions, the need for a user to manuallytake such action may be reduced over time.

In some embodiments, a desired “minimum (at least this) time betweenplays” of a composition may be based upon the amount of the user'srating and/or preference for that composition. For certain compositionsthat have a low user “rating or preference”, the user may want to hearthese compositions much less frequently, and hence it may be desirableto attempt to keep the time between playbacks greater than a “minimum(at least this) time between plays”. As shown in the example of FIG. 7f, when the user “rating or preference” is below a “low threshold”, thenthe “minimum (at least this) time between plays” may be utilized by thesystem. Note that if a user is (often) forwarding past a compositionbefore it has completed playback then: 1) the user rating or preferencemay be decreased; and/or 2) the relationship [e.g., curve/function/etc]may be changed/adjusted to cause an increase in the “minimum (at leastthis) time between plays”.

In some embodiments, the “time between plays” may be determined orinfluenced by the ratio of “current likeability divided by peaklikeability”. As the example in FIG. 7 c shows, the “time between plays”may increase as the “current likeability” decreases relative to “peaklikeability”.

It may also be useful to define different types of “time between plays”.First, there may be a “no more than X time between plays” for newcompositions that the user has indicated significant positive feedbackand hence wishes to hear frequently. Second, there may be an “at least Xtime or greater between plays” for older favorites that the user stilllikes somewhat but no longer wants to hear as often.

Note that embodiments may be implemented using positive and/or negativemeasures of the user's rating or preference. For example, many of theexamples in this specification are illustrated using a positive ratingor preference, where the greater the user's likeability or want of acomposition, the greater the magnitude of the user's rating orpreference. Alternatively, those skilled-in-the-art, will realize thatequivalent results may also be obtained by defining negative typeparameters, which indicate the user's amount/magnitude ofdislike/desire-to-avoid the composition. For embodiments using thesenegative measures, the higher the negative-type rating, the more theuser dislikes or desires to avoid the composition.

In some embodiments, a re-schedule queue 65 may be used to hold anordering of compositions ordered by their next playback time.

Updating the “time between playbacks” of a composition, directly fromuser actions:

In other alternative embodiments, the updated “time between playbacks”of a specific composition, may be updated/determined by using arelationship to adjust the prior “time between playbacks” based on a newaction(s) by the user [e.g., new user action(s)]. FIGS. 20, 21, and 11show examples of these relationships.

FIG. 21, shows a family of relationships (e.g., curves) that may bedefined for different user action(s). Each relationship (e.g., curve)may be unique for each user action or unique for each differenttype/category of user action. For example in FIG. 21, if a user-action-Coccurs for a composition, then the prior “time between plays” value(2701) may be updated to a new value (2702) by using the relationship(e.g., curve) for user-action-C. If a different user-action had occurredthen a different relationship (e.g., curve) may be used.

The relationship shown in FIG. 20 shows an example of a relationshipwhere user-action-A indicates a positive/likeable user interest in thespecific composition. Note that for this relationship that the each ofthe prior “times between plays” will be updated to a shorter timebetween plays, so that the user will then experience this compositionmore frequently.

The user-action-F curve in FIG. 21 is an example of a relationship whereuser-action-F indicates a negative/dis-like user interest in thespecific composition. Note that for this relationship that the each ofthe prior “times between plays” will be updated to a longer time betweenplays, so that the user will then experience this composition lessfrequently.

FIG. 11 shows an alternative example where the relationship may bedefined by using a look-up table. In this example, user-action-jindicates a positive/likeable user interest in the specific composition.Note that for this relationship that the each of the prior “timesbetween plays” will be updated to a shorter time between plays, so thatthe user will then experience this composition more frequently.

FIGS. 26 a and 26 b show another alternative embodiment for updating thevalue for time between playbacks of a specific composition, followingthe occurrence of a user-action associated with that specificcomposition. As shown in the example in FIG. 26 b, if the user-action isto “forwards past (skips-past) composition within 2 seconds ofexperiencing a composition” (an indicator of dis-like), the prior valuefor the “time between playbacks” for that composition is increased by10×, so the user will experience that composition less frequently.

Note that a user may make erroneous/accidental or unintended useractions (e.g., control actions). In addition, the system maymisinterpret the user's meaning/intent of any single control action.Hence, it may be desirable that the magnitude of the adjustment to the“time between playbacks” for a composition will not be excessivelyadjusted by a single user action by itself. Therefore, in someembodiments, the amount of adjustment to the “time between playbacks”due to new user action, may also depend on the extent that the neweruser action is consistent with previous user action(s) for thatcomposition. That is if a newer control action is consistent with prioruser action(s) then the user's intent may be more confirmed, and hencethe magnitude of the adjustment may be increased/larger. Alternatively,if a newer control action is inconsistent with prior user action(s) thenthe user's intent may be less certain, and hence the magnitude of theadjustment may be reduced.

FIGS. 26 c shows an example of an (optional) embodiment were the amountof adjustment to the “time between playbacks” may be dependent on thenumber of consistent or inconsistent that previously occurred for acomposition. Assume that “user action t” is a dislike indicator (e.g.,indicates the user dislikes the composition). As shown in FIG. 26 c, thegreater the number of prior “dislike” user actions, the more the “timebetween playbacks” is increased by a newer dislike user action.Alternatively, a greater the number of prior “like” user actions, theless the “time between playbacks” is increased by a newer “dislike” useraction.

FIG. 26 d shows an example of another (optional) embodiment, where theamount of adjustment for a user action may depend on both the newer useraction, as well as what specific prior user action(s) occurred.

Determining “time between playbacks” of a composition, by using a“play-count”:

A target or desired “time between playbacks” of a composition may alsobe determined as a relationship/function of the “number of times heard”.In some embodiments, the time between playbacks of a given compositionmay be determined by using relationships(s) to user's rating/preferenceand/or the number of times the composition was heard by the user.

FIGS. 7 b and 7 j show examples of how the “time between playbacks”(“time between plays”) may be varied based upon (e.g., as a function of)the number of times a composition has been heard by the user. The numberof times a composition has been heard by the user may sometimes bereferred to as “play-count” by those skilled in the art.

FIG. 7 b shows example curves of “time between plays” versus “number oftimes heard” and the psychological “complexity of the composition”. Whena composition is new to the user (and the user has indicated positivefeedback) the time between plays is shorter. Eventually, as userlikeability decreases with familiarity, the time between plays isincreased. The user may tire of compositions with a lower psychological“complexity” more quickly than those with a greater psychological“complexity”. The likeability functions may be constructed based onaggregate user feedback of users that are considered similar to theuser.

In some embodiments, it may be useful to carefully distinguish betweenseveral different “play-count” parameters such as: a) the number oftimes initiated; b) the number of times played completely; c) the numberof times played partially; d) the number of times initiated by useraction; e) the number of times initiated without user action due to ashuffle/random-playback mode) 0 the number of times initiated as part ofa playlist g) the number of times initiated by a customized (to theuser) music selector. Another alternative/additional parameter to “playcount” (with similar distinguishable cases) is the “cumulative playbacktime” that the specific composition has been heard by the user (i.e.,=sum of all the playback times for the user for that composition). Notethat, the relationship(s)/function(s) may differ for these differentdefinitions of play-count.

Using a combination of methods to determine a “time between playbacks”:

In some embodiments, a combination of the above methods may be utilizedto determining a “time between playbacks” of a composition.

For example, the magnitude of a rating determined by using user actions(method above), may be further adjusted by an additional amount that isdetermined by utilizing a relationship (method above) that defines the“time between playbacks” versus “play-count” (e.g., number of timesheard or amount heard). In this way, the magnitude of a rating of acomposition for a user may be adjusted as additional playbacks occur,even if no user actions have occurred that are associated with thatcomposition.

In some embodiments, the method which is estimated to be more accurateor which is based on more user actions or more data; may be chosen foruse. In other embodiments, a combination of the multiple methods may beaveraged or mathematically combined (e.g., values from the 2 closestmethods may be averaged) to determine a “time between playbacks”.

Determining when a composition will be played again:

FIG. 23 shows one embodiment of a flow chart for determining when aparticular composition will be played for the user again, by using anupdated value of the user's rating/preference; or new user action(s); orthe updated “play-count”.

Note that in general several different definitions of time may be usedand there may several different definitions of the “time betweenplaybacks” (“time between plays”) of a composition (e.g., when thatcomposition is played again for the user). Depending on theembodiment/situation, the time between plays may be the “elapsedcalendar time since last playback” or the “playback-time of all othercompositions since the composition was played”.

In some embodiments, the “time between plays” may refer to a “deltaplayback time” (during which other compositions are played) until thecomposition will be played again. The value for the “delta playbacktime” may be determined by using a relationship(s) [such as FIGS. 7 a-7j, 11, 20, 21, and 24-26; or any of their mathematical equivalents]. Anexample is shown in FIG. 23 at element 2302. For example, for acomposition for which the user has a fairly high positiverating/preference (e.g., fairly high likeability), the composition maybe replayed again for the user after 3 hours (e.g., =“delta playbacktime”) of other compositions have been played for the user. In thiscase, a running “cumulative playback time” (sum of the playback time ofall compositions) may be maintained by the system. A target “nextplayback time” for a composition may be calculated by: adding the “deltaplayback time” value to the “cumulative playback time” value at the timethe composition finished its last playback. An example using the“cumulative playback time” is shown in FIG. 23, element 2304.

In some other embodiments, the “time between plays” may be determined bythe “calendar time” or “clock time” that has elapsed since the last timethe specific composition was played. For example, for a composition forwhich the user has a fairly low positive rating/preference (e.g., fairlylow likeability), the composition may be replayed again for the userafter 6 months (e.g., =“delta real-time”) of real-time calendar/clocktime has elapsed. In this case, a “real-time” may be maintained by thesystem (which advances 1 second for each 1 second of actual real-time).A target “next playback in real-time” for a composition may becalculated by: adding the “delta real-time” value to the “real-time”value at the time the composition finished its last playback.

Note that in some embodiments, a combination of these two methods ofestablishing a target time between playbacks of a composition may beused. For example, for higher rated/preferred compositions the “timebetween plays” may utilize a “delta playback time” (e.g., based on theamount of time that other compositions have played). While, for lowerrated/preferred compositions the “time between plays” may utilize a“calendar time” or “clock time” (e.g., based on the amount of real-timethat has elapsed since the last time the specific composition wasplayed). A break-point threshold value of preference/rating may beestablished that determines which of these two relationships to use foreach value of the user rating/preference.

Note that the time between playbacks (plays) of each given composition,may be used as approximate target values. The system will automaticallyattempt to schedule the playback of a composition. But the target timewill not be exactly achievable for various reasons. Example of neededadjustments from the targeted values include: the user may not be usinga user-device (e.g., off) at a certain time; or the user may havemanually requested that some composition be played at that time; ormultiple compositions may be targeting the same/overlapping timeperiods. The system scheduler will need to adjust the scheduled playbacktimes when these cases occur. The resolution of these schedulingconflicts may introduce a variation in playback by the system that maybe useful in reducing system repeatability/predictability that mightbecome noticeable to some users.

In an optional embodiment, the target playback time may be additionallyvaried around the target playback time, in-order to further reduceexcessive repeatability in the system. In one embodiment, the targetplayback time is randomly varied within a target window or a definedamount about the target playback time. This may be useful forcompositions have a high user rating/preference and there is a shortertime between playbacks; where a repeating/similar time between playbacksof a particular composition may be more noticeable to the user. In oneembodiment, the target time may be randomly varied by a defined amountabout the target or randomly varied within a window about the target. Inone embodiment, a plus or minus percent-variation (e.g., 20%) may beused around the target. This variation may be defined by parameter(s)whose value may differ for an individual composition, group ofcompositions, or context. For example, instead of using the exact “deltaplayback time” of 3 hours as defined by the relationship (e.g.,curve/function); a value in the target window/range of 2.4 hours (−20%)and 3.6 hours (+20%) is randomly chosen to establish the next target. Anexample of varying the “delta playback time” around a target value isshown in FIG. 23 at element 2303.

Alternative Embodiments of the Relationship(s):

Note that these relationships may be defined uniquely for eachcomposition; may be common for a set of compositions; and/or may becommon for all compositions of a user. For example, a uniquerelationship (e.g., such as FIGS. 7 a-7 j, 11, 20, 21, and/or 24-26) maybe uniquely defined/used for one composition. Alternatively, a commonrelationship may be used for all compositions that are in a certaingroup of compositions. Or, a common relationship may be used for allcompositions. Or a combination of these.

Depending on the embodiment, the relationship(s) may be non-linear (asshown in FIG. 7 d), or linear (as shown in FIG. 7 i). Depending on theembodiment, the relationship(s) may be monotonic (e.g., FIG. 7 d) ornon-monotonic (as shown in FIG. 7 j). Depending on the embodiment, therelationship(s) may be continuous or non-continuous.

In some embodiments, a unique relationship (e.g., curve or function) maybe optimized and/or used for each composition. In some embodiments, onerelationship (e.g., curve or function) may be shared and/or used for aplurality of different compositions. For example, a plurality ofcompositions of a similar complexity or a plurality of compositions of acommon type/genre; may use the same relationship (e.g., curve orfunction). In some embodiments, the relationships (e.g., curves orfunctions) may be optimized/customized for each composition used by eachindividual user. Or various combinations of these may be used.

Note that these relationships may be defined uniquely for eachcomposition; may be common for a set of compositions; and/or may becommon for all compositions of a user. For example, a uniquerelationship (e.g., such as FIGS. 7 a-7 j) may be used for onecomposition. Alternatively, a common relationship may be used for allcompositions that are in a certain group of compositions. Or, a commonrelationship may be used for all compositions. Or a combination ofthese.

Although curves are showed in FIGS. 7 a-7 j for ease of illustration,actual implementations may utilize any equivalent mathematical methodincluding: lookup tables; linear or non-linear equations; polynomials;digital differential analyzers (DDA); database(s); mathematicalfunctions [e.g., f(x)= . . . ]; formula(s) or any other equivalentmathematical relationships known by those skilled in the art.

For example, the values of a curve, may be defined by a table/databasewith separate columns for X-axis (e.g., number of times heard) andY-axis (e.g., time between playbacks) discrete values. Using the X-value(e.g., number of times heard), the corresponding Y-value (e.g., timebetween playbacks) may be determined by looking-up its correspondingvalue in the table. Non-discrete cases [e.g., magnitude of a user'srating expressed as a real number; say 0.572] may be handled by usingthe closest value available in the table or by interpolating between theclosest available values in the table.

In some embodiments, the values, coefficients, and/or parameters used inthese mathematical relationship(s) may be determined by fitting to thedata, in-order to define a relationship within an acceptable error. Forexample, the order and the constants of an nth-order polynomial may beselected to fit a set of target data within a desired margin of error.Alternatively, the equivalent of a polynomial equation may beaccomplished by using a digital differential analyzer (DDA).

Depending on the embodiment, a unique relationship (e.g., curve orfunction) may be optimized and/or used for each composition. In otherembodiments, a relationship (e.g., curve or function) may be sharedand/or used for a plurality of different compositions. Depending on theembodiment, the relationships (e.g., curves or functions) may also beoptimized/customized for each individual user and/or each compositionfor each individual user. The values, coefficients, and/or parameters ofrelationships may be determined by fitting to the data in-order todefine a relationship within an acceptable error.

Using Aggregate Data to from many users to determine therelationship(s)/parameters:

The relationships (e.g., curves) that are used for a specificcomposition; may be automatically determined by using the aggregatefeedback/user-actions to the specific composition from other users thatare considered similar to the user.

For example, FIG. 7 a (or its mathematical equivalents) may beautomatically generated by using the aggregate ratings of many otherusers (“similar” to the user) as those ratings varied with play-count.As a simple example, the rating values of the other similar users may beaveraged at each incremental value of the play-count, to determine therelationships shown in FIG. 7 a.

The system performance/user-experience may be improved over time. Onemeasure of performance/user-experience is the number of actions thatuser(s) took, because the system is not automaticallysatisfying/adopted-to the user. Another measure ofperformance/user-experience; is the number of user-actions that aredislike indicators, which indicate the number of compositionsautomatically provided to the user which the user did not like/enjoy.One objective is to minimize the need for the user to take action(s) toenjoy the adoptive personalized entertainment.

In general, any/all of the relationships/values/parameters may beautomatically improved over time, by testing newrelationships/values/parameters with a sample of users and thenobserving the whether the actual performance/user-experience isimproved, relative to the old relationships/values/parameters.

In some embodiments, experts may determine the newrelationships/values/parameters to be tested with a subset of users bymanually analyzing the aggregate experience/feedback from multipleusers. In other embodiments, the system may automatically determine thenew relationships/values/parameters to be tested with a subset of users;by automatically analyzing the aggregate experience/feedback frommultiple users.

With continuing test sampling to a subset of users and comparing theresulting performance/user-experience against the results with thepreviously used relationships/values/parameters, theadaption/customization of the system may be continually improved overtime.

Composition Sequence Generation:

FIG. 6 is a functional diagram for one embodiment of a real-timesequence generator 60. The sequence generator may operate in real-time,in-order to immediately respond to user control actions 61 such as“forward”, “back”, “pause”, “play”. The sequence generator is able toautomatically transition between immediately responding to user controlactions and automatically generating a customized sequence ofcompositions (entertainment program) for the user.

The sequence generator may automatically enter the customized programmode whenever all prior user control requests have been completed andthe user is not currently providing control actions to affect thecomposition sequence. For example, if the user manually requests thatcertain song(s) be played, then those songs are played and after theuser's manual requests have been completed; the sequence generator mayautomatically begin playing an automatically generated sequence ofcompositions that is customized for the user.

When in the customized program mode, a primary determinate for the “IDof the next composition to be played” 67 is the position (setting) ofthe “Favorites-New” control 41. When in the favorites position,compositions are chosen based on the likeability ratings of compositionsbased in the “user's history” 64.

In some embodiments, if the user's list of favorites is short, thencompositions and highlights that are new to the user may be interspersedalong with the user's favorites to provide sufficient compositionvariety and to allow automatic expansion of the user's list of favoritesand/or the user's collection.

In some embodiments, a re-schedule queue 65 may be used to hold the IDof each composition that is targeted for playback and its correspondingnext targeted playback time. The compositions may be ordered by theirnext targeted playback time. The re-schedule queue may be implemented bya “linked list”. A link list may allow a composition to be easily addedinto any location (e.g., targeted playback time) in the queue (e.g.,between two compositions already in the queue); by only changing onelink in and adding one new link to, the linked list. Other methods knownto those skilled in the art may also be used. As noted elsewhere in thisspecification, depending on the embodiment, the time between plays maybe the “elapsed calendar time since last playback” or the “playback-timeof all other compositions since the composition was played”.

In some embodiments, a re-schedule queue 65 may be used to hold theuser's favorites ordered by their next playback time. When a compositionhas finished playback (or been forwarded-past/terminated), the user'srating and/or “number of times played” (for that composition) may beautomatically updated by using the relationship (e.g., FIG. 7 a-7 j) forthat composition. Based on the updated value(s), the “time betweenplaybacks” may be determined. The newly determined value for “timebetween playbacks” may be added to the “current cumulative playtime” todetermine a targeted future “cumulative playtime” for that composition.Similarly, the newly determined value for “calendar time betweenplaybacks” may be added to the “current calendar time” to determine thefuture “calendar playback time” for that composition.

An ordered list of the locally available new compositions 62 and anordered list of the locally available highlights 63 may be used todetermine the order they are presented to the user or interspersed withthe user's favorites. When the sequence generator has decided toplayback a new composition or highlight, the next one on these lists maybe played. The selection of the compositions on these lists and theirorder on these lists may be determined as described in the sectionentitled “Selection of New Compositions and Highlights”. Onlycompositions for which the user has usage-rights and that areimmediately available locally may be included on this list. Somecomposition-providers may allow a certain number of free plays for auser in the hopes that the composition will become a user favorite andbe purchased and added to the user's collection.

The sequence generator 60 maintains a record of the “user history” 64locally which is updated with all the user's control actions and thehistory of composition playback. When scheduled and when networkconnectivity is available, the sequence generator 60 may provide “userhistory updates” 66 back to the experience-provider. The update may onlyinclude new [and may exclude previously forwarded] user historyinformation.

An example of the “user history” 64 data elements is shown in FIG. 5.Shown at the top of each column in FIG. 5, are parameters that may becaptured for each composition the user has heard. The parametersmaintained for each composition may include the following: 1) A unique“composition number (Comp #) used to identify each composition. 2) Theuser's usage-rights token for each composition. 3) Whether thecomposition is available locally. 4) The user's current enjoymentrating. 5) The user's peak enjoyment rating. 6) The number of times thecomposition was heard. 7) The play history including the date/time whenthe composition was last heard. 8) The target time between playbacks. 9)The user feedback history representing the positive and negative usercontrol actions related to the composition. 10) The likeability curves,equations or functions that apply to the composition which may beidentified by a pointer, filename or other identifier.

In some embodiments, the sequence generator 60 may be implemented as aplug-in software module, so that continually improved versions may becreated by the experience-providers or sequence generator providers.

Using “Highlight” Segments to Introduce New Compositions:

In some embodiments, highlights (i.e., composition samples) may also be(optionally) included in the customized entertainment sequence. The useof “highlights” may allow the user to more quickly discover pleasingcompositions that are “new” to the user. “New” to the user meanscompositions that the user has not yet heard or is not yet sufficientlyfamiliar with. This would include compositions that have been availablefor many years but the specific user has not yet experienced. It alsoincludes those compositions that have been recently released but thespecific user a limited familiarity with. A composition that wasreleased years or decades ago may be considered as “new” to the user.Highlights may be interspersed with full compositions in the customizedentertainment sequence. New highlights are custom selected for each userbased upon the probable likeability (enjoyment) as estimated from theuser's history and/or profile and/or credit/payment history.

Each highlight (i.e., highlight snippet/segment or composition sample)may comprise highly compelling portion(s)/part(s)/subset(s) of acomposition. In some embodiments, the most compelling are thoseportion(s)/part(s)/subset(s) of a composition that user(s) and/or “new”user(s) will quickly appreciate/feel/sense as being emotionallysatisfying; interesting; desirable; and/or uplifting. In someembodiments, compelling may relate to the ability to influence/causeusers to purchase the usage-rights for a “new” composition and/or to addthe “new” composition to the user's collection.

For more embodiments, the duration of each “highlight” may be differentand optimized for each composition. Alternatively, in some otherembodiments, the duration of the “highlights may be standardized. Forexample, in some embodiments, each highlight may be an approximately 10to 20 second long sound segment comprised of the more highly compellingportion(s)/part(s)/subset(s) of a composition. If an embodiment useshighlights with durations of 10-20 seconds [and assuming a typicalcomposition-duration of 3 to 5 minutes], then the use of highlights mayincrease the user's discovery of new music by a factor of about 10 to 20times or more.

The most compelling part(s) of a composition may be manuallypre-selected by artist(s), expert(s), focus group(s), and/or based onaggregate user feedback. For example, a plurality of possible“highlights” may be created. For example, the different “highlight”possibilities may be played to focus group(s) of users, and thencollecting/measuring how compelling the users found each of thehighlight possibilities. In this way, the more compelling “highlight”can be determined. In some embodiments, such testing/measuring, may alsobe done for different demographic/interest/etc groups.

In another embodiment, a plurality of possible “highlights” may betested using the aggregate feedback of a plurality of different groupsof randomly selected users. In one embodiment, each “highlight”possibility may be sample tested with a separate group of randomlyselected users. For example, highlight1 is tested with group1;highlight2 is tested with group2; highlight3 is tested with group3; etc.The “highlight” that had the largest/most positive response with agroup, may then be chosen as the most compelling “highlight” of thosetested and may then be used for all users in the future.

The highlight (sound segment) may utilize storage and/or playbackformat(s) that are similar to any other composition (only they are ofshorter length).

A highlight may be free for a limited or unlimited number of plays by auser. In some embodiments, the experience provider may obtain marketingusage-rights for a highlight or composition in-order to introduce andmarket the composition to a user. Such marketing usage-rights may be fora limited number of plays or limited amount of usage time or have otherlimits imposed on user usage.

The user-device may include an audio or visual indicator to aid the userin distinguishing between a highlight and a full composition. Suchindicators may be located before, within, and/or after: the highlightand/or composition.

Highlights (and new compositions) may be interspersed with userfavorites based upon user indication(s) of the amount of their interestin “new” compositions. For example, the user may indicate their desirefor “new” compositions by manually entering/adjusting a setting at auser-device, via an interactive display or other type control input. Forexample, highlights (and new compositions) may be interspersed with userfavorites based upon the “favorites-new” control (slider) 41 setting ofFIG. 4. Highlights may be interspersed more frequently; the closer the“favorites-new” control 41 is to the “new” position.

In one embodiment, when the slider 41 is in an extreme newness position(uppermost position), the user-device 22 will enter the highlights-modewhere the user may hear a sequence of composition highlights so that theuser is exposed to a larger number of compositions in a shorter periodof time. The highlights-mode allows each user to discover new pleasingmusic and to expand their collection of compositions at a higher rate.

Typical user control actions may be captured as user history (feedback)while each highlight is being played. This may include skipping(“Forward”) when the user dislikes the highlight (indicating negativefeedback) or jumping backward (“Back”) if the user wishes to hear thehighlight again (indicating positive feedback) or activating (pressing)the “like” control (indicating positive feedback). In some embodiments,while the highlight is playing, the user may activate (press) the “Play”control to immediately hear the full composition (also indicatingpositive feedback). After the full composition has finished (and theuser has not provided other control actions), the “highlights” mode mayresume playing other highlights.

When the user indicates sufficient positive feedback, while a highlightis playing, the composition may be added to the user's list of favoritesor potential favorites. When the user indicates sufficient negativefeedback while a highlight is playing (such as forwarding past it), thathighlight (and “similar type” highlights) may be less likely to bepresented to the user. If the user does not provide any feedback or aweak feedback, while a highlight is playing, that highlight may bepresented to the user for re-consideration (and user feedback) at alater time.

Since the user might activate a control in error, the user ratings of acomposition should not be excessively affected by a single user controlaction. Rather the user ratings for a composition may be graduallychanged based upon feedback from multiple exposures to the compositionover a period of time. For example, it may take several playbacks of acomposition over a extensive period of time, in which a “Forward” (skip)was consistently activated early during the composition playback (andthere was no other positive feedback), in-order for the user's rating ofthat composition to become so negative that it would not be presented tothe user again.

When the user's list of favorites is too small to generate a sequencewith an acceptable time between replays of the user's favorites, thesequence generator may intersperse more new compositions and/orhighlights between the user favorites. In this manner, a user's list orcollection of favorites may be naturally expanded, when required,without requiring any special user actions to search for and locate thenew compositions.

When the sequence generator is in the favorites mode and the userappears to be disliking and forwarding over much of the music, theuser-device 22 may recommend that the user move toward the “new”position on the “Favorites-New” slider 41. Alternatively, the slider 41may be automatically moved toward the new position so the user will beexposed to more new compositions that are likely to be pleasing to theuser. In addition, an increased number of new highlights may beautomatically interspersed by the sequence generator.

The user-device 22 may include a mechanism for the user to approve theacquisition or purchase of a new composition(s) or the usage-rights fora new composition(s). For example, the user-device display may displayinformation about the new composition such as its purchase price andpurchase terms while the composition or its highlight is playing. Orsuch information may be communicated to the user by audio prior to orfollowing the playback of the composition or highlight. A sale orbargain price may be offered to the user. To confirm a purchase, theuser may take control action such as activating a certain control orperhaps speaking a certain word or phrase. Of course, some purchaseplans may not require approval of each purchase.

Selection of New Compositions and Highlights:

A process for generating a “recommended list of new compositions and/orhighlights for the user” 87 which is customized for each user is shownin FIG. 8. The recommendation generator 82 for new compositions andhighlights may utilize the user's history 66 and common likeabilityindexes (composition mapping indexes) 80 a & 80 b, in-order to provide acustomized experience for each user. The “recommendation list” 87 foreach user may also be dependent on the “Meta-catalog of compositions andhighlights available to the user” 85. The meta-catalog available to agiven user may not include all the compositions available in the world.The meta-catalog 85 available to a user may be limited due toconsiderations that may include: the user's subscription plan or userpurchase limitations or limitations imposed by a particularexperience-provider.

A common likeability index may contain a mapping of “if likedcomposition(s)” then “also liked compositions”. An example of simpleone-to-one likeability index of compositions (i.e., composition mappingindex 80) is shown in FIG. 9. For each “if liked composition #” shown incolumn 1 a list of “also liked composition Ws” are listed in column 2.For example, if composition 854108 is liked then compositions 883491,103293, and 527177 will probably also be liked. This mapping may bedetermined by some combination of experts, focus groups, or by ananalysis of the aggregate feedback of all users. If the aggregatefeedback of all users is employed, then the index may keep track ofadditional parameters such as “# Users mapped”, “# users liking both”and “% users liking both”. The aggregate “likeability” mapping analysismay be based on either “current likeability” or “peak likeability”values for the composition.

An example of a more complex many-to-one likeability index (mapping) ofcompositions is shown in FIG. 10. For each group of “n” (=3 in FIG. 10)“if liked composition #” shown in columns 1 to 3, a list of “also likedcomposition Ws” are listed in column 4. For example, if compositions854108, 883491 and 107389 are liked, then compositions 230845, 632952and 428503 will probably also be liked. To reduce searching, the indexesmay be maintained in numerical order and/or with numericalcross-references.

When a new composition is first released it may be considered to be“untested” since no aggregate user history is available. “Expert andfocus group opinions” 86 may be used to perform an initial “untestedlikeability analysis” 81 b. Based on the initial index (mapping) 80 b,the new composition may be sampled (possibly as highlights) to a limitednumber of users in-order to obtain “aggregate user feedback” 84 a fromenough users to perform a “common likeability index analysis” 81 a andcreate an aggregate composition mapping index 80 a. Once the “aggregatelikeability analysis” 81 a is based upon a sufficient amount of“aggregate user feedback” 84 a (i.e., exceeds an “aggregate feedbackthreshold” 83 b), the aggregate index (mapping) 80 a may then replacethe initial expert generated likeability index 80 b. In this way,untested new compositions are not widely distributed to new users untilan initial aggregate feedback establishes their likeability with asmaller number of users. In this manner, a greater variety of newcompositions may be each initially tested with a small subset of allusers without burdening any one user with many untested compositions.Alternatively, “cutting edge” users may be offered the option ofsubscribing or activating a special “untested” mode and to be exposed toa greater number of untested compositions. A “rate of untestedcompositions” parameter 83 b may be used to control each user's desiredamount of exposure to “untested” compositions and/or highlights.

A list of recommended new highlights and/or compositions for each usermay be generated in advance at the experience-provider's networklocation. The list is ranked and ordered based on compositions that aremost likely to be pleasing to the user. Depending on the rankings andquantity of highlights previously downloaded and still unused at theuser-device, some or all of the highlights in the revised highlight listare downloaded into the user-device 22 so they are immediately availableif requested by user action. The full composition may also be downloaded at the same time as the highlight so it is immediately availableif the user requests the full composition be played upon hearing thehighlight.

Another optional enhancement, is to additionally constrain therecommended new compositions and highlights based on “user contentrestrictions” 83 a. Each composition may be pre-tagged by restrictioncategories, by the content providers or content rating providers.Restriction categories may be based on factors such as the user's age,language, violence, sex content, etc. The content restrictions aresettable by either the user or the user's guardian (through passwordprotection), in-order to prevent the recommendation and playback ofhighlights/compositions from undesired categories.

Inserting “New” or Marketed Compositions and/or Highlights intoPlaylists:

Those skilled in the art will realize that a sequence of compositionsmay also be generated by system that is able to operate on a playlist.Generally, a playlist is a group of compositions that a user candesignate for playback. When a playlist is activated for playback, thecompositions in the playlist are played back in sequence. One example ofa playlist is a list of compositions that a user has manually selected(e.g., “my favorite dance songs”). Another example of playlists are the“smart playlists” available in later versions of the Apple iPod. Smartplaylists are also described in U.S. Pat. No. 6,941,324 (by Plastina, etal of issue date Sep. 6, 2005), which is incorporated herein byreference.

One disadvantage of smart playlists is that they can only utilize/selectfrom compositions that are already in a user's collection or for whichthe user already owns/has-purchased usage-rights for. Hence, smartplaylists are not able to market “new” compositions (that are notalready in a user's collection or for which the user does not alreadyown usage-rights for).

In some embodiments, for each playlist, the user may optionallyinput/select a value that defines the fraction of marketed compositionsthat will be automatically inserted into a playlist. For example, foreach playlist, the user may optionally input/select a value for thedesired “percent marketed compositions to automatically insert intoplaylist”. For example, the user may select between 0% and 100% marketedcompositions. For example, if the user where to input a value of 50%,then about half the compositions played will be either marketedcompositions and/or highlights of marketed compositions. For someembodiments, a starting/default value may be defined and used for allplaylists, unless the user inputs another value for a particularplaylist. In some embodiments, the “factory” starting/default value, maybe set to zero percent (or any other value).

As described elsewhere in this specification, “new” or marketedcompositions may be automatically custom selected for user based uponthe user's profile; feedback; usage history; credit; and/or paymenthistory. In addition, as described elsewhere in this specification, themarketed compositions may also be selected for their similarity ormatching (e.g., likeability indexes) to other compositions that arealready in a user's specific playlist.

As described elsewhere in this specification, an experience-provider mayobtain, for the user, limited/marketing usage-rights for the marketedcompositions, prior to allowing the marketed compositions to be playedas part of a playlist. In some embodiments, the user marketed percentagesetting may not be satisfied if enough usage-rights for marketedcompositions, cannot be obtained because of a user's bad credit/paymenthistory.

In some embodiments, new playlist “filtering” parameters may be addedinto smart playlist systems. Examples of these new parameters include:“marketed composition”; “new composition”; “count of number of marketedplays”; “number of marketed playbacks remaining”; “marketed highlight”;“new highlight”; etc. As with other smart-playlist parameters (as inU.S. Pat. No. 6,941,324 by Plastina), the smart playlist system mayassociate a value for each of these parameters with each composition.The user may then define a smart playlist that filters out compositionsthat satisfy the filtering values the user defined. For example, theuser may define a playlist that filters/selects “marketed compositions”or “highlights”; that also have “count of number of marketed plays” of 2or greater. For this example, a playlist may be automatically generatedthat includes all the compositions that satisfy the parameters that theuser has defined.

“Share” Mode:

Another optional enhancement is the “share” mode/capability. This allowsone user to share a share list of composition(s) with a second user. Thefirst user identifies the user ID where the share list of compositionidentifier(s) is to be sent to. The share list is forwarded across anetwork such as the internet to the second user's profile. If the seconduser accepts the share list from the first user, those compositionswhich are “new to the user”, may be added to the second user'srecommended new compositions and highlights list 87. Later, highlightsor the full compositions are presented to the second user. Thosehighlights or compositions then receiving favorable feedback are thenadded to second user's favorites list (user history).

In an alternative embodiment, the share list is transferred directlybetween user-devices via electromagnetic or sound waves (for example, RFor IR transmission such as Bluetooth) with or without the use of anetwork. The second user-device 22 then automatically forwards the sharelist to their experience-provider 26 for possible incorporation into thesecond user's “recommended new compositions and highlights list” 87.

User Channels, Moods and/or Categories:

The user-device 22 may optionally allow the user to create a pluralityof uniquely defined channels, each for a different user mood, activity,event or category of music. For example, the user may desire a dinnermusic channel, dance music channel, commuting channel, romantic channel,etc. As with a normal radio, at power-on the user-device 22 may startplaying at the last channel the user was at.

In one embodiment, each channel may be defined to be handled by adifferent experience-provider. For example, the user may selectexperience-provider 1 for their rock music channel while selectingexperience-provider2 for both a romantic channel and a classic musicchannel. The user may be able to instantly switch betweenexperience-providers by simply switching channels via a change channelcontrol.

The user's channels may be accessed via the “My” channels control 43 ashown in FIG. 4. In one embodiment, the favorite (most used) userchannel starts playing when the “My” channels control is activated(pushed). The remaining user channels are ordered from most used toleast used and are reached using the channel “up” 43 c and “down” 43 dcontrols. The list may be wrapped around so pressing “up” 43 c when at“most used” channel will wrap to the “least used” channel. Pressing“down” 43 d at the “least used” channel may wrap to the “most used”channel. If the user has only defined one channel, then the “up” and“down” controls wrap on the single channel and hence do not cause achannel change. As shown in FIG. 4, the display 40 may indicate the nameof the current user channel playing and how many other user channels areavailable. The display may include a channel slider 44 to indicate wherethe channel is relative to the user's favorite channel (based on theuser's history of channel activity and feedback). A slider 44 positionat the top may be used to indicate the user's most favorite channel. Aslider 44 position at the bottom may be used to indicate the user'sleast favorite channel. The size of the slider relative to the sliderrange may be used to provide an indication of the size of a channelrelative to the total number of user channels. For example, if there are5 user channels then the size of the slider is displayed as one fifth ofthe slider range.

The user may begin the creation of a new user channel by activating the“Create” channel control 43 b. The user now has access to a plurality of“starting” channels (possibly 100′s) via the channel “up” 43 c and“down” 43 d controls. Each of these channels may be provided by adifferent experience-provider.

In one embodiment, each “starting” channel may be playing “highlights”representing a different mood or category of music. The ordering of the“highlights” channels may be based on the user's history (and theaggregate experience of similar users), so that the most likely pleasing“highlight” channels for each user, require the fewest pushes of thechannel “up” 43 c and “down” 43 d controls. The user provides feedbackabout each channel by the amount of time spent at a channel. The useralso provides feedback on each “highlight” while it is playing via the“forward” 42 c, “back”42 f, “like” 42 g and “play” 42 d controls. Allthe feedback history is retained for use the next time the “createchannel” mode is entered. Once the user has generated a threshold amountof positive feedback on a “highlight” channel, a new user channel may beautomatically added to the user's channel list. Until the user hasprovided a second higher threshold of feedback, the new channel may tendto provide a larger number of highlights in-order to allow the user tomore quickly tune the channel to the user's preferences.

As another optional capability, the user would be able to define aplayback by artist, album, title, time period, musical category, etc orsearch a catalog based on such parameters.

Methods for deleting, splitting and merging channels may be incorporatedinto the user-device.

Different “starting” channels may be created by the same or by differentexperience-providers but all channels may utilize a single, commoncollection of user usage-rights tokens.

Acquiring Usage-Rights for a User:

In one embodiment, the usage-rights may be issued by thecomposition-providers 23 and then stored in the usage-rights repository24 so the usage-rights may be used by all experience-providers 26.

FIG. 14 shows an example of the acquisition of usage-rights for a user.An experience-provider 26 may handle the acquisition of the usage-rightson the user's behalf. Login-Info at the user-device is used to determinethat a specific user is active at the user-device and has authorized theacquisition 1414 of usage-rights for a composition. The acquisitionrequest is communicated 1412 to the experience-provider and validated.The experience-provider 26 may submit a “purchase-order and payment”1403 to a composition-provider 23. The composition-provider 23 mayoptionally request a credit-report 1409 from the identity-provider(banker) and receive back 1408 a credit report on the user's account. Ifacceptable, the composition-provider 23 creates and places 1405 a copyof the user's new usage-rights for the composition in the usage-rightsrepository 24. The composition-provider 23 may communicate 1404 orderstatus/completion to the experience-provider 26. If theexperience-provider does not yet have a copy, the composition-provider23 may also forward 1404 a copy of the composition to theexperience-provider. The experience-provider 26 may now “get” 1406 thenew usage-rights from the usage-rights repository 24. The usage-rightsrepository 24 then forwards 1407 a copy of the new usage-rights to theexperience-provider 26. The experience-provider 26 may now package andforward 1413 the composition (in the format needed by the user-device)and the corresponding usage-rights (e.g., a reduced-capacity-token) tothe user-device. The new composition is now available for use at theuser-device. From time to time, the experience-provider 26 may invoiceand request a credit-report 1410 from the identity-provider (e.g.,banker) and receive back 1411 payments and credit-reports for the user'saccount.

The experience-provider 26 may also request free highlights or freesamples from a composition-provider 23 on the user's behalf. If thecomposition-provider 23 determines that the user's credit-report isacceptable, the composition-provider 23 may then issue a token forhighlights or samples into the usage-rights database. The tokens forhighlights or samples may be for only a limited number of plays, and maybe set for each user based on history of the username and/or the creditreport.

In some embodiments, duplicate purchases of usage-rights (e.g., bydifferent experience-providers) may be detected in the usage-rightsrepository so duplicate tokens may be revoked and credited back to theuser's account. The user is relieved of any concern with accidentallypurchasing a composition the user already owns, since any suchoccurrence is automatically detected and the payment is automaticallycredited back to the user's account.

Contents of a Usage-Rights Token:

The tokens may be defined so that they may be easily transferred acrossthe network and shared by multiple experience-providers or otherproviders. An individual token may be defined as a separate entity suchas an object or data structure or file. Each token's contents may alsobe stored as a record in a database.

FIG. 13 illustrates one detailed embodiment of the contents of ausage-rights definition 1301 (i.e., usage-rights token or ownershiptoken).

The owner of the token may be defined by a token-owner 1304 definitionin the token 1301. Each token 1301 may be defined for exclusive use by aspecific user (e.g., an individual) or a set of specific users (e.g., afamily).

The token-owner 1304 may indicate the actual identity of the owner ormay refer to the owner in a unique but anonymous manner.

In some embodiments, the token contents are defined to maintainownership confidentiality and privacy, so the actual owner's identitymay be not be determined by either: inspection of the token 1301 byitself or by the experience-providers (and other providers) by using thetoken 1301 in combination with other information theexperience-providers may have.

In one embodiment, the ownership of the token may be defined by ananonymous-ownerID 1304 a from which the actual user may not be directlydetermined. An identity-provider 29 (e.g., banker) may maintain aconfidential mapping between the anonymous-ownerID and the actualowner's identity. In-order to maintain user privacy and identity, theother providers may be prevented from accessing this mapping and theidentity-provider 29 may be prevented from accessing the tokens andusage-rights repository 24.

In some embodiments, the ownership of the token may be defined by anencrypted-anonymous-ownerID 1304 b. Public key encryption (e.g., aprivate-public key pair) may be used so that the identity-provider 29encrypts the anonymous-ownerID with a private key. The authorizedproviders may validate (but not decrypt) the encrypted-anonymous-ownerIDby using the public key. Digital signatures may also be used. The actualowner's identity may not be determined from either the anonymous-ownerIDor the encrypted-anonymous-ownerID.

In some embodiments, the ownership of the token may be hidden within anencrypted and digitally signed package 1304 c that may only be decryptedby the identity-provider. Public key encryption (e.g., public-privatekey pair) may be used where the token issuer encrypts theanonymous-ownerID with a private key and the encrypted username may bebe validated (but not decrypted) by other authorized providers by usingthe public key. Or a combination of encryption and digital signaturesmay be used.

In addition, the identity-provider 29 may maintain a secure privatedatabase 1506 that maps the Login-Info to: the anonymous-ownerID 1304 a;and/or encrypted-anonymous-ownerID 1304 b; and/or the encrypted anddigitally signed package 1304 c. The identity-provider 29 may maintainanother secure private database 1504 that maps the anonymous-ownerID andis not accessible by any other providers.

The anonymous-ownerID 1304 may include a reference to theidentity-provider 29 that issued the anonymous-ownerID. The token mayalso include a link; hyperlink; pointer; or universal resource locator(URL) to a network 27 location where the identity-provider 29 mayvalidate the existence of the anonymous-ownerID and the status of itsassociated account.

The token-owner 1304 may also be defined using a combination of theabove methods and/or other user identification methods known by thoseskilled in the art.

Each token issued may have a unique token-ID 1302.

Each token may also include the token-issuer 1303. The token-issuer 1303information may include a link; hyperlink; pointer; or universalresource locator (URL) to a network location where the token may bevalidated by the token issuer.

Each token may also include the issue-date/time 1305 andcomposition-provider information 1306. Each token may also define acomposition-ID 1307. Each version of a composition may have a uniquecomposition-ID 1307 assigned to it. For example, the studio and eachdifferent concert version of the same song by the same artist may have adifferent composition-ID.

The token 1301 may also include composition description information 1308such as the composition-name, artist, artist version, compositionrelease and performance dates, etc.

The token 1301 may also include the definition of the owner'susage-rights 1309 (ownership-rights) such as the TimePeriod Valid;Number of Plays Allowed; fee per play; an unlimited plays until date;end-date; number of copies allowed; allowed type of user-devices;execution-rights; etc.

In some embodiment, tokens may authorize playback with all existingformats and all (networked) user-devices. Sales of usage-rights mayincrease when users are more confident of the compatibility and thefuture usability of their purchased compositions.

In one embodiment, tokens may authorize playback of the composition withfuture formats and future user-devices, perhaps with a small one-timeadditional fee. This may eliminate user concerns that their purchases ofusage-rights may be worthless if the technology evolves or changes inthe future.

The token may also so include a token purchase record 1310. The user'spurchase record may include information such as Date & Time tokenPurchased; Purchase Order ID; whether upgraded from a prior token-ID(s);Amount Paid; Cumulative Amount Paid; Form of Payment; etc.

The token may also include an encrypted information area 1313 where thetoken-issuer may encrypt and digitally sign private information that thetoken-issuer alone may use to validate the token as being valid anduncompromised. Multiple levels/schemes of encrypted, hidden, codedinformation may be used to maintain token integrity even if some levelsor schemes become compromised. The token issuer may also maintain aseparate secure and private database of issued tokens that may be usedto validate tokens.

One or more digital signatures 1314 may be used to allow detection ofunauthorized changes to a token or sub-sections of a token. Thesignature may be derived from a hash function such that the value of thesignature is related to all the signed data and the alteration of anysigned data will result in a different signature value. Public-Privatekey signatures [e.g., public key encryption (PKI) methods] may be used.The signature may be generated with a private key that only the tokencreator knows. Any experience-provider 26 or other authorized provider(or user-device) may then use the corresponding public key to validatethat the token has not been altered since it was issued.

The contents & structure of the token may be defined by an industrystandard or standards defined by the experience-providers and/orcomposition-providers. Portions of the token may be defined using amark-up language such as the Extensible Markup Language (XML) with aschema definition that defines each element.

In some embodiments, the token may be formatted, reformatted,repackaged, encrypted and digitally signed in different ways dependingon where and how the token is being used on the network. For example, inone embodiment a tokens in the usage-rights repository may be stored asa record in a (relational) database. The format and/or contents of theusage-rights tokens stored in the usage-rights repository may differfrom the reduced-capacity-tokens that are distributed to a user-device.Also in some cases, the format of certain reduced-capacity-tokens mayneed to be compatible with the digital rights management scheme that isproprietary to a user-device.

There are many alternative implementations that are functionallyequivalent. Many alternative embodiments are possible within the scopeof the claims.

Identity-Provider and the Anonymous-ownerID:

To protect user privacy, it is desirable that a user's usage-rightslibrary and play-history not be associated with an actual person. Thismay be accomplished by the creation of an anonymous-ownerID used todefine the ownership of usage-rights (tokens). The experience-providers,usage-rights repository and composition-providers may manage and use theusage-rights and play-history for each anonymous-ownerID without anyknowledge of who the actual person is.

An anonymous-ownerID may be created by an identity-provider 29 that isindependent from the other providers (e.g., experience-providers,usage-rights repository and composition-providers). In one embodiment,the anonymous-ownerID may include additional information that identifiesthe identity-provider 29 that manages the anonymous-ownerID account. Tomaintain user privacy, the identity-providers 29 are not allowed accessto any of the databases of the other providers (experience-providers,usage-rights repository and composition-providers).

FIG. 15 shows an example of the creation of an anonymous-ownerID andlogin-Info by an identity-provider. The user submits a “user applicationfor an anonymous-ownerID account” 1502 to an identity-provider 29 thatis independent from the providers (e.g., experience-providers,usage-rights repository and composition-providers). In one embodiment,the user may provide information that actually identifies the user suchas user name, address, and contact information. The user may alsoprovide biometric identification information. The user may also provideinformation that is used to unambiguously identify the user in the caseof a future identity theft such as one or more secret security questionsand answers. The identity-provider 29 may “process the user applicationfor an anonymous-ownerID” 1503. A globally unique anonymous-ownerID isassigned to the user by the identity-provider 29 and stored in a securedatabase 1504 along with the submitted application information. In someembodiments, the anonymous-ownerID is not provided to the user.

The identity-provider 29 then “defines login-Info” 1505 that the usermay use to uniquely identity themselves to user-devices. The login-infomay include multiple ways that the user may identify themselves to auser-device. Each user-device 22 may be capable of recognizing somesubset of the login-info in-order to uniquely identify the presence ofthe user at the user-device. This mapping of login-info toanonymous-ownerID may be maintained by the identity-provider 29 in asecond secret database 1506.

The “login-ID's (and other login-Info) may be issued to the user” 1501which define the various ways the user may login at user-devices.Multiple login-ID's may be issued to the user. Which types of biometricmethods (finger print scan, face recognition, iris scan, etc) thatvarious user-devices may utilize, may be defined to the user.

The identity-provider 29 may provide to authorized providers (e.g.,experience-providers) the “translation of login-info to ananonymous-ownerID” 1507 and the validation of the login-info and theaccount status for the corresponding anonymous-ownerID.

The identity-provider 29 may also provide an “anonymous banker function”1508 for the account of the anonymous-ownerID. The providers may submitto the banker “invoices, requests for credit-reports and identitydisputes” 1509 related to an anonymous-ownerID and receive back“payments, anonymous credit-reports and identity resolution status”1510. The banker may use the databases 1504 and 1506 to performanonymous billing for the account of the anonymous-ownerID. The bankermay submit “invoices and status” 1511 to the user and receive payments1512 from the user.

The identity-provider 29 may also resolve issues related to identitytheft or compromises of an owners account by using the other informationin the owners application (e.g., security questions or more extensivebiometric info).

The compromise of a login-ID or other login-info may be corrected byissuing new login-ID or login-info while revoking the compromised ones.The database 1506 login-info may be remapped to the newanonymous-ownerID.

The compromise of an anonymous-ownerID may be corrected by revoking thecompromised anonymous-ownerID and the associated tokens, while issuing anew anonymous-ownerID and the associated replacement tokens. Thedatabases 1504 and 1506 login-info may be remapped to the newanonymous-ownerID.

The compromise of the actual user identity due to public associationwith an anonymous-ownerID may be recovered by the issuing a newanonymous-ownerID and associated tokens while revoking the olderversions, as above.

Usage-Rights Repository:

In one embodiment, the composition-providers or usage-rights repository(i.e., usage-rights authority) may provide a guarantee to users thattheir usage-rights tokens will be secured in perpetuity (i.e., at leastfor the life of the usage-rights tokens and the user and their heirs).This type guarantee will assure users that all their purchases (acquiredusage-rights tokens) will be available automatically from the repositorywithout requiring any user involvement, management or action by theuser. When a user purchases the usage-rights (ownership-rights) for acomposition, they may be confident that their usage-rights will beautomatically usable through all experience-providers and by most (orall) user-devices without requiring any user actions.

To provide additional user confidence in the guarantee, the usage-rightsrepository (i.e., usage-rights authority) may be industry wide fundedand may maintain an endowment large enough to fund the usage-rightsrepository in perpetuity. The usage-rights authority may charge thecomposition-providers a small fee (which includes endowment funding) foreach entry they make into the database. Since the costs of maintaining atoken in the repository are expected to decrease over time due tocontinuous technology improvements, an endowment funded model may beutilized to support token availability in perpetuity.

A separate repository may be provided by each composition-provider 23 ora common repository(s) may beshared by a group of composition-providersor a common repository may be used by all composition-providers.

The usage-rights repository(s) may be implemented using a databaseincluding a relational database. The token-owner and tokenID may be usedas common data keys across the relational database. The usage-rightsrepository may also be implemented as web server; with theexperience-providers, composition-providers, etc interacting as clients(in a client-server model). Those experienced in the art will realizethat other alternatives may also be used.

Many copies of a repository may be distributed across multiple computersconnected to the network 27 or Internet so that access may be providedby multiple network paths and multiple physically isolated repositorylocations in case of failures or heavy traffic loads. The repositoriesmay be maintained concurrent by using mirroring or other methods forkeeping multiple copies synchronized across a network. In addition, therepositories may also be backed up and/or archived periodically[including to other media] across the network(s) preferably at differentphysical locations from the repositories.

Each composition-provider 23 may also maintain a secure version of theusage-rights data that is not accessible by any of the other entities.If the repository accessible data is damaged or corrupted, therepository may be rebuilt using the secured non-accessible version. Allthe composition-provider databases may be backed up frequently tomultiple secure locations distributed at different physical locationsacross the network 27 or internet.

Only authorized composition-providers may be allowed to write or updatethe usage-rights repository. In one embodiment, eachcomposition-provider 23 may only add new entries or update theusage-rights entries they have created. A composition-provider 23 may beprevented from accessing the entries of other composition-providers. Theusage-rights authority may maintain a private database of authorizedcomposition-providers that are allowed to access the usage-rightsrepository. Composition-provider 23 access may be controlled by uniqueprivate composition-provider-ID and a password.

In one embodiment, all usage-rights tokens in the repository (orrepositories) are read accessible by all authorizedexperience-providers. The usage-rights authority may maintain a privatedatabase of authorized experience-providers that are allowed to read theusage-rights database. Experience-provider 26 access may be controlledby unique private experience-provider-ID and a password.

The usage-rights repository may not be accessible to certain providers(e.g., identity-providers) or to the general public over the internet.

In some embodiments, the usage-rights repository(s) may also maintainthe status of each token. The token-status indicates whether a token isvalid or invalid. A token may become invalid because of a token upgrade,token compromise, identity-theft, identity-compromise, etc.

In-order to provide greater database integrity, the database may beconstructed so previously entered records may not be deleted or changedbut earlier entries may be updated by the addition of a more currentdatabase entry. Database records may include one or more changeableparameter(s) which may point-to or indicate a newer record exists. A logof all database record changes and accesses may also be maintained soproblems may be traced back to their source.

To facilitate rapid access to a given token-owner's usage-rights, alookup table (database) may be used to translate from a token-owner (&perhaps compositionID) to the network 27 addresses of one or morecomputers (or storage devices) where the specific physical location(s)where the token-owner usage-rights are stored. Such lookup may beredundantly distributed at different physical locations across thenetwork. An implementation similar to that used for the Internet'sDomain Name Servers (DNS) may be utilized. Those skilled in the art willrecognize that many other alternative implementations are possible.

User Feedback and Play-History:

User play history is a record of the user's interaction/feedback abouteach composition the user has experience. This record may include usagedate/time; experience-provider; % of composition played; how theplayback was initiated; and other similar information. The users playhistory may be used by an experience-provider 26 to automatically createa customized personalized sequence of old and new compositions that willbe pleasing to each user.

In some embodiments, the play history may include a usage-history ofeach token. In other embodiments, the play-history may be an aggregatehistory for each user where the play-history of upgraded tokens andre-issued tokens for the same composition are combined together.

The user-history may be maintained in a database by either the user, bythe usage-rights repository or by the experience-provider(s) or otherprovider. In one embodiment, user's play-history may be stored in theusage-rights repository with access provided to allexperience-providers.

The contents & structure of the play-history may be defined by anindustry standard or standards defined by the experience-providers andother providers. Portions of the play-history may be defined using amark-up language such as the Extensible Markup Language (XML) with aschema definition that defines each element.

FIG. 16 shows an example of the contents of a user's play history for acomposition (for a unique user). The play-history may include ananonymous-ownerID 1304; the composition-ID 1603; and a record-of-play1604 for each time the user experienced the composition. Theplay-history may also include a parameter that points to the last record1605. The play-history may also include parameters that summarize theuser's experience with the composition such as “number of times played”1606 and “average % played” 1607. The play-history may also include oneor more validation hashes (digital signatures) 1608.

FIG. 17 shows an example of the contents of a “record-of-play “n” 1604.The record-of-play may include the “date & time played” 1702; the“experience-provider coordinating the playback” 1703; the % played 1704;the “usage-rights token-ID used” 1705; likeability indicators 1707; and“how initiated” 1707. The “how initiated” may indicate whether it wasautomatically chosen without user input or how the user specificallyrequested the composition to be played (library search or using “back”control or other ways). The record-of-play may also include “reportingstatus” 1708 to indicate whether the record-of-play has already beenreported to the next higher play-history collection point. Therecord-of-play may also include one or more validation hashes (digitalsignatures) 1709.

Distribution of Digital-works to User-Devices:

FIG. 18 illustrates one embodiment for distributing digital-works to auser-device. In some embodiments, a subset of these steps may be used.In some embodiments, the steps may be performed in a different order.

The first step in FIG. 18 is to “Obtain Login-Info anduser-device-feedback information from the user-device” 1802. When a useris active at a user-device, the user-device 22 may capture Login-Infoin-order to identify the specific user. The user-device-feedbackrepresents prior usage-history and user-feedback since the last time theuser-device-feedback was successfully transferred. This information maybe sent from the user-device 22 across the network 27 to theexperience-provider 26.

Since a given user-device 22 may be compatible with a limited number ofdigital-work formats, the user-device 22 may also forward itsdevice-type to the experience-provider 26 so the experience-providerwill know the particular formats that the user-device requires.

The Login-Info may include entry of the user's LoginName/password; aspoken user codeword (such as a LoginName/password); user voicerecognition; user-biometrics (e.g., face recognition, fingerprintrecognition, iris scan recognition); a User Radio Frequency ID (RFID)Tag identification device; a user-ID device or any other method ofuniquely identifying a user. In-order to protect against the actualidentity of the user, biometric information may be limited to a portionof the full biometric data or a processed summary of the biometric data.Combinations of these identification methods may be used to reduce thefalse-positive and false-negative identification error rates.

In some embodiments, the user may be uniquely identified from theLogin-Info but the actual identity of the user may not be obtained fromthe Login-Info.

The next step is to “Translate the Login-Info into an Anonymous-ownerID”1803. In one embodiment, the Anonymous-ownerID may correspond to thetoken-owner parameter(s) 1304 of the usage-rights token definitions forwhich that user has rights to utilize.

In one embodiment, the Login-Info to Anonymous-ownerID translation maybe performed by an identity-provider 29 which maintains a mapping ofLogin-Info to Anonymous-ownerID's. Only authorized providers may beallowed to request a Login-Info to Anonymous-ownerID translation.

The Login-Info may also be validated against the experience-provider'sdatabase of Login-Info that previously occurred.

The next step is to “Validate the Anonymous-ownerID” 1804. Theidentity-provider 29 may maintain status on the validity of theAnonymous-ownerID. The status may indicate whether there is compromiseof a user's identity (e.g., identity theft) or unusual suspect activityin the user account. The identity-provider 29 may also maintain ananonymous credit report about the Anonymous-ownerID that may be used toassess the trustworthiness and reliability of the user.

The experience-providers may also “validate the Anonymous-ownerID” 1804by monitoring for indications of piracy, identity theft or stolenuser-devices 22. This may include examining the user-history for unusualactivities such as a) the simultaneous use of multiple user-devices atdifferent physical locations; b) unusual or excessive non-reporting backof user-history from user-devices; c) errors or corruption of formatsand digital signatures; d) an excessively large number of user-devices.

Once the Anonymous-ownerID of the user has been determined andvalidated, the experience-provider 26 may “obtain and validate all thetokens owned by the anonymous-ownerID” 1805 from the usage-rightsrepository. The validity of each token may be validated usingtoken-status that may also be maintained in the usage-rights repository.Bogus tokens may be detected and excluded during validation. Tokenstatus may also be used to revoke a token that has been compromised orrevoked/re-issued.

The next step is to “Determine digital-works needed by the user-device”1806. These may be digital-works related to the current context of theuser-device 22 such as digital-works that the user has requested; ordigital-works in the user's library; or digital-works in a user'splaylist; or a sequence of digital-works defined specially for the user.In one embodiment, the determination of possibly needed digital-worksmay be based upon the user's playback-history and/or the user'sfeedback-history.

The next step is to “Prepare digital-works and usage-authorizations informat needed by the user-device” 1807.

Each user-device 22 may provide information (e.g., model & serialnumber) that allows the experience-provider 26 to determine the specificformats required by each user-device. A user-device 22 status may alsoindicate which digital-works and validated usage-rights are alreadyavailable at the user-device.

In some embodiments, the highest quality format that is compatible withthe user-device (where the user is currently at) may be automaticallydetermined by using the user-device information and then automaticallydownloaded to the user-device. In some embodiments, the need for and thedownload may occur in anticipation of being needed in the future at theuser-device.

In some embodiments, the highest quality format which is compatible withthe user-device (where the user is currently at) and that is availableto send to the user-device; may be automatically determined by using theuser-device information and then automatically downloaded to theuser-device. In some embodiments, the need for and the download mayoccur in anticipation of being needed in the future at the user-device.

In some embodiments, the full usage-rights (usage-rights token) is nottransferred to the user-device 22 but is gradually released to theindividual user-devices by using a limited usage-authorization (e.g.,reduced-capacity-token). A reduced-capacity-token (i.e. authorization touse the digital-work) may have less than the full definition ofusage-rights and may typically expire before the full usage-rightsexpire. The reduced-capacity-tokens may be periodically re-issued orupdated when feedback from a user-device 22 confirms that theusage-rights are being properly used. In this manner, the usage-rightsare gradually metered out to the various user user-devices; as long asthe activity (e.g., feedback) of the user-device 22 is considerednormal.

In some embodiments, a downloaded digital-work may be enabled forplayback at a user-device 22 by a reduced-capacity-token that is usableonly by a specific user or set of specific users; on the specificuser-device 22 and only for a limited authorized-time or limited numberof playbacks. The authorized-time may be hours to several days and/orfor a limited number of plays. To continue playing the digital-work, theuser-device 22 must provide feedback to the experience-provider 26across the network 27 and receive back an updated reduced-capacity-tokenfrom the experience-provider. Otherwise, the reduced-capacity-token mayexpire before the user's full usage-rights have expired.

The reduced-capacity-token may allow the digital-work to be played onthe user-device for only a limited time period (for example, for only anhour or a day or a few weeks). The user-device 22 may periodicallyinteract with the experience-provider 26 across the network 27 tofeedback user-history and to receive an extension of the time period. Ifthe user-device 22 does not connect back to the experience-provider, thedigital-works will expire after the usage-authorization time period. Thetime period may be set for each user based on estimated usertrustworthiness factors such as the user's anonymous credit reportand/or the historical experience with a user. For example, the timeperiod may be set long for a reliable customer with an extensivepositive history. If a user-device 22 is prevented from reporting backthe user-history or is lost or stolen, the digital-works in theuser-device will expire after the time period but the full usage-rightsheld in the usage-rights repository are not compromised or affected.

In some embodiments, a user-device 22 is not authorized to create copiesthat can be transferred to other user-devices. Since the user'scollection is automatically backed-up via the network repository andsince each user-device 22 is able to acquire any needed digital-worksautomatically across the network, there is no longer a need for users tomake copies themselves so reduced-capacity-tokens may typically bedefined to not allow copies to be created at user-devices.

A special case occurs with user-devices that do not have a real-timenetwork connection capability or are never within reach of a real-timenetwork connection. For this case, a portable user-device 22 may be usedto act as a “transportation delayed” network connection. Thereduced-capacity-tokens in the portable user-device are immediatelydisabled upon their transfer to an un-networked user-device. When theuser finishes with the un-networked user-device, the user-history andusage-rights are then transferred from the un-networked user-device backto the portable user-device. When the portable user-devicere-establishes a real-time network connection, the user-history(including that of the un-networked user-device) is feedback to theusage-rights repository. To handle this special case, digital-works andtheir corresponding reduced-capacity-tokens are allowed to betransferred between user-devices as long as no copying occurs (i.e.,user-devices are not allowed to create additional copies).

The next step is to “Send the digital-works and usage-authorization(e.g., reduced-capacity-token) to the user-device” 1808. In someembodiments, digital-works and their corresponding usage-authorization(e.g., reduced-capacity-tokens) may be automatically distributed acrossthe network 27 by the experience-provider 26 in the appropriate formatfor the user-device as needed or in anticipation of being needed.

Once a compatible version of the digital-work and the correspondingusage-authorization (e.g., reduced-capacity-token) are at theuser-device, the user-device 22 may use an unexpired usage-authorizationto access (e.g., decrypt) and use the digital-work whenever the user isactive at the user-device.

Network Strategies:

It is expected that each user will have multiple user-devices that needto be updated such that any changes to the user's history and user'scollection (i.e., the user's library of compositions) is automaticallymade available, in a timely manner, to all the other user-devices wherethe user is active. For example, any changes made in the automobile onthe way home may be immediately available, in the ideal, to user-devicesin the user's home.

In one embodiment, each user-device 22 would be capable of establishingtwo way communication in-order to interact with the experience-provider26 over a wireless or wired connection to a network such as theinternet.

When the user-device 22 has sufficient storage, the user's favorites maybe stored locally and the general network strategy is to download themost likely needed compositions and highlights well in advance of actualneed by the user-device. Having storage in each user-device 22 is moreaccommodating to poor quality, intermittent, or missing networkconnections.

When a local user-device 22 has sufficient local storage, the networkinterface may be managed to minimize communication costs. For example,the largest downloads and uploads may be scheduled during those times(of the day or night or week) when the communication costs are lower.For example, downloads of new compositions and highlights may occur,automatically without user action, in the middle of the night and thenstored within each user-device 22 for possible use during the followingdays. More information may be downloaded than is typically expected tobe needed, just so it will be available if needed. Since the typicaluser's tastes change slowly over a period of days, the locally storedcompositions and highlights will be fairly up-to-date; but anautomatically generated sequence of compositions may be less then idealwhen switching between user-devices (e.g., car to house), since the mostrecent user history would not be exchanged until later that night. Ifdesired, the less data intensive user history/feedback may becommunicated more frequently, while the more data intensive downloadsare restricted to lower cost communication times.

Another alternative is to broadcast and/or multicast the data intensiveinformation (compositions and highlights) to multiple userssimultaneously over the network. Prior to the broadcast or multicast,each user-device 22 receives an update on what new compositions andhighlights that user needs. The user-devices then monitor the broadcastor multicast, and save the appropriate data the user is expected toneed.

User-devices may also network directly with each other and/or over anetwork to pass update information.

In one embodiment, where networked access is not available in remotelocations, the update to the remote user-devices may be handled by aportable user-device carried from a networked area into the remote area.The portable user-device then networks with the remote user-devices toupdate them. Similarly, after leaving the remote area andre-establishing a network connection. The portable user-device mayupdate the repository with the user feedback that occurred in the remotearea. In this case, the user-devices may directly interact to shareinformation when they are within communication range with each other.Such direct communication may be accomplished by IR or RF means such asWiFi or Bluetooth.

Some embodiments may (optionally) employ/utilize streaming over anetwork connection such as the internet. With streaming, thepersonalized sequence is generated at the experience-provider's locationon the network 27 (e.g., internet server) and forwarded, wired and/orwireles sly, to the user-device as a stream of packets. The user-devicemay be simplified since it only need convert the packets into theentertainment sequence (e.g., sound sequence) and send the user'sfeedback back across the network 27 to the experience-provider.Streaming may reduce the needed amount of local storage and localprocessing in the user-device. In some embodiments, a small local memory(such as a FIFO or double buffer) is used in the local user-device toprovide a continuous sound stream on the output side, despitefluctuations in the receipt and processing of packets across the networkconnection. A possible disadvantage of streaming is that a virtuallycontinuous interactive network connection at an effective bandwidth mustbe available. Another possible major disadvantage is that the networkconnection must have an acceptably low interactive latency so theexperience-provider's streaming source may quickly adjust to the user'sfeedback and control inputs (such as the “Forward” and “Back” controls).The need for a higher quality network connection to be continuouslyavailable may make streaming a less desirable alternative for someembodiments.

Implementation of the Inter-Provider Network:

In some embodiments, the information transfers across the network 27between the providers (experience-providers, composition-providers,usage-rights-repositories, and/or bankers) may provide good security andprivacy along with a good Quality-of-Service (such as high availability& low latency).

The physical network layer may be a combination of optical fiber, wiredand wireless (EM, RF, IR, optical) networks. The network 27 architecturemay be configured using elements such as add-drop multiplexers(electrical and optical), routers, switches, gateways, bridges, andfirewalls. Network availability may be improved by providing redundantnetwork paths, redundant servers (at different physical locations) androbust network architectures such as mesh networks. Existing internetinfrastructures may be used but security and quality of service issuesshould be considered.

Quality-of-Service (QoS) parameters such as latency may be improved bythe use of Multi-Protocol Label Switching (MPLS) or GeneralizedMulti-Protocol Label Switching (GMPLS) which may route messages throughpre-defined un-congested network paths thereby reducing queuing delays,timeouts and re-transmissions. Forward error correction may allowcorrection of transmission errors at the receiver and reduce delays fromre-transmissions.

To improve security, the network routers and firewalls at the entry toeach of the provider locations may be configured to only accept trafficfrom authorized IP addresses. Virtual private networks (VPN's) may alsobe used across the network 27 or Internet to provide an additional levelof privacy between the sender and receiver.

An even higher level of security and service may be provided with adedicated network 27 between the experience-providers,composition-providers, usage-rights-repositories, and bankers that iscompletely separate from the Internet. Isolation may be accomplishedusing dense wavelength division multiplexing (DWDM) optical networkswhere separate DWDM channels (light frequencies) and routers arededicated to the inter-provider network and not shared with internettraffic or traffic from any other networks. Such a separate network maybe isolated from Internet problems such as excessive traffic or denialof service attacks. As an example, Broadwing Communications offers aConverged Services Network infrastructure based on Multiprotocol LabelSwitching (MPLS) that will enable both Layer 2 and Layer 3 VirtualPrivate Network (VPN) that is separate from the Internet.

Those skilled in the art will realize that there are many models ofdistributed processing and communication that may be used to implementthe disclosed concepts. These include the client-server and peer-to-peermodels. In the various embodiments, different functions may beimplemented by using a combination of these different models.

Those skilled in the art will realize there are many network andinformation transfer protocols that may be used in a hierarchical mannerin the network. The protocols may be configured or layered in terms ofthe 7 layer ISO/OSI network model or other protocol layer models (e.g.,Internet or Darpa) to meet requirements for security and quality ofservice (QoS) such as latency, lost packets or messages, errordetection, control, message/packet retransmission, etc. Examples ofprotocols include Sonet, Frame, Asynchronous Transfer Mode (ATM),Internet Protocol (IP), Transfer Control Protocol (TCP), User DatagramProtocol (UDP), Ethernet, File Transfer Protocol (FTP), and Hyper TextTransfer Protocol (HTTP). Examples of secure transfer protocols includeHyper Text Transfer Protocol Secure (HTTPS), Secure-HTTP (S-HTTP), andSecure Sockets Layer (SSL).

In some embodiments, remote procedure calls (RPC) may be used forcommunication between the providers; or between the user and theproviders. For example, a first provider acting as a client, mayconstruct a request as an extensible markup language (XML) message andsend it across the network 27 using hypertext transfer protocol (HTTP)to a server at a second provider. The server at the second provider maythen process the XML message and then send an XML formatted message backacross the network 27 using HTTP to the client application at the firstprovider.

Those skilled in the art will realize there are many alternativeapproaches such as the simple object access protocol (SOAP); the commonobject request broker architecture (CORBA); and others.

Information transfers may be encrypted and digitally signed. Encryptionprevents the information from being read or used by those without adecryption key. Digital signatures may be used to allow the detection ofany addition, removal or alteration of the information after it wascreated, for example during later transit or storage.

There are many methods of encryption and digital signatures known tothose skilled in the art. In one embodiment, public key encryption maybe used, where there are pair of keys consisting of a public keyavailable to all information senders and a private key known to only tothe receiver. The information sender encrypts the information using aknown public key of the recipient. Only the recipient is able to decryptthe information using a private key known only to the recipient. Theinformation encrypted with the public key may not be decrypted using thepublic key. Determining the private key from the public key and theencrypted message, in-order to decrypt the message, requires animpossibly large amount of computation.

In the case of digital signatures, a public-private key pair may beused. The message sender uses a private key known only to the sender tocompute a signature whose unique value depends on all the information inthe message. The digital signature is generated using a one way hashfunction. The receiver may verify that the message hasn't been alteredsince creation, by obtaining a known value after computing the receivedmessage & signature with the sender's public key. If the message orsignature was altered in any way after creation, the known expectedresult is not obtained. Examples of hash functions include MD5 (128 bit)and SHA-1 (160 bit).

Certificate authority or authorities may also be used to control theissuance and validation of digital certificates so that a sender mayvalidate that the public keys are truly those of the intended recipientbefore encrypting & signing a message. For an additional layer ofprotection, access to these public keys and certificates may be limitedto authorized entities in-order to prevent access to inter-providercommunication methods by the general Internet public.

The RSA algorithm, which is widely used on the Internet, is one exampleof public key encryption. Those skilled in the art will recognize thereare many other alternatives to encryption and digital signing (digitalsignatures) that may also be used.

Alternatively, a private key(s) may be used for both the encryption by asender and decryption by a recipient. Those skilled in the art recognizethat the distribution of the private keys may be accomplished viain-person meetings, in-person telephone call-back exchange protocols orother methods that do not rely on the same digital network.Alternatively, private key exchange between authorized entities, may beaccomplished across a digital network by numerous approaches such as theDiffie-Hellman Key Agreement Method (IETF RFC 2631) [along with sourceauthentication by the prior exchange of digital signatures to defeat aman-in-the-middle attack].

Only authorized provider entities with a known entityID (and password)may be allowed to send information transfers. EntityID's and passwordsmay be initially established between entities using other methods wherethe identities may be established by personal meeting or otherencryption methods discussed above. Each authorized entity may berestricted to certain types of information transfers or transactions.

Networking Between User-devices and Providers:

A major consideration for the network 27 between theexperience-providers and the user-devices is a wide area of coverage. Inthe ideal, all user-devices may be able to connect to the networkautomatically either wireles sly or wired, no matter where a user-device22 is currently at. In some embodiments, this ideal network access maynot be practical and/or cost effective for some geographic locations. Inone embodiment, each user-device 22 will typically be able to access thenetwork 27 from time to time in-order to be periodically validated bythe experience-provider 26 by feeding back user-history, receivingadditional compositions and to extend the usage-right time period forcompositions stored in the user-device. Depending on the embodiment,network access may range from being essentially continuous to onlyoccurring periodically once every few minutes; hours; day(s); orweek(s).

For security and performance reasons, the network 27 between the users(user-devices) and the providers may be different from the network 27used between the various providers (experience-providers,composition-providers, usage-rights-repositories, and/or bankers).

In one embodiment, a public network such as the Internet may be used forcommunications between the providers and the user-devices, because ofits widely available access. Alternatively, a separate network,different from the Internet, may be used between the providers and theuser-devices. Or a combination of public and private networks (forexample: cell phone network; WiFi; and/or WiMax networks) may beutilized. For example, it may be desirable for user-devices to access auser's private home network (e.g., WiFi) in-order to connect to theexperience-provider 26 via the Internet.

Any combination of the network architectures, configurations andprotocols discussed elsewhere may be used to secure informationtransfers between the experience-providers 26 and the user-devices 22.

Business Models:

The disclosed concepts enable many different schemes for generatingrevenue and/or royalties for the experience-providers, networkproviders, composition-providers, composition creators and artisticperformers. The schemes include:

-   -   Fee for each composition each time it is played.    -   One time fee for unlimited play of a composition by the user.    -   A fee per minute or hour of experience provided to the user.    -   A flat fee per month independent of the actual user usage.    -   Advertisement supported, where the user may listen to and        possibly interact to a certain amount of ad time per a        predefined amount of non-ad user time.    -   A certain number of free plays followed by some fee for play.    -   Number of user-devices.    -   Number of user-devices simultaneously active.    -   Amount of data transferred across the network.    -   Various combinations of the above.

The experience-providers may simultaneously manage each of these billingschemes for different groups of users, so the billing scheme may becustomized for each user. The history of the aggregate usage for eachcomposition may also be used to determine royalties for the compositioncreators, composition owners and other service providers.

The composition-providers may offer various purchase plans. Theexperience-provider 26 may mediate to acquire the best price for theuser based on expected user needs.

In some embodiments, the composition-providers may price usage-rights sothat the cost of gradually expanding the usage-rights to full-rights, isthe same as if the full-rights we purchased initially. By alwaysguaranteeing the best price and eliminating user concerns about pricing,sales may be increased.

The experience-provider 26 does not need to store an individual libraryof compositions for each user. The actual compositions may be stored ina common library that is shared by all users and accessed based upon auser profile maintained for each user. The amount of access bandwidthprovided for each composition may be adjusted to match aggregate userdemand. For example, a currently popular composition that is beingdownloaded by many users may be made available from many servers acrossthe network 27 in-order to meet the demand. While a less popularcomposition may be made available from significantly fewer servers onthe network.

As an optional enhancement, the user may be allowed to use the “forward”control to skip any offensive or unwanted advertisement (ad).Alternative ads are then presented to the user until the required userad time is satisfied. When the user wants additional information aboutthe product in an ad, the user activates (presses) the “like” control.Additional information is then presented. The user may also activate the“back” control to hear an ad again in-order to repeat needed informationsuch as a phone number or address. The user's account is credited forthe additional ad time heard. The user's use of the “forward” and “back”controls during ads may be used to more closely target future ads to theuser.

Various encryption schemes may be utilized in-order to protect frompiracy or user attempts to interfere with the collection of billinginformation.

Initial System Customization to the User:

To more efficiently perform customization of the system for each user, alarge display with an interactive user interface may be utilized acrossa network 27 during the initial user customization process. The user mayanswer forms on the user's interests, hobbies, categories or products ofinterest, etc.

This may include the establishment of methods for confirming the user'sidentity at the start of future user-device sessions. This may includecapturing sound to be used for voice recognition of the user's name orother specific words, biometrics measurements of the user such asfingerprint on the start control, or camera imaging of the user's face.

The user may also indicate initial preferences for advertisementcategories. In this mode, the user may be presented with differentproduct categories and product types for which the user may use the“Like” control to indicate relative interest in.

The user may also wish to customize of the type and frequency of news,weather, traffic, etc based on the day of week, time of day, location ofuser, etc.

The initial preferences the user provides are only the starting point.User feedback, indicated by normal user control actions, is utilized tocontinuously adopt the entertainment sequence more uniquely for eachindividual user.

User History Timeline:

In another optional extension, the actual timeline of a user's historyof feedback and favorites may be made available to the user via aninteractive interface and display. As an example, the user would be ableto review what was listened to at any earlier time period or timeinterval, for example a particular day, week or month during the collegeyears. Such a history review mode or capability may not be needed formost types of user-devices.

User Provided Compositions:

In another optional extension, the user would have the capability ofproviding compositions and highlights to the system. This is useful incases where the user may have created their own compositions or acquiredthem locally or where the experience-provider 26 does not have access tocertain compositions.

Hardware and Software Embodiments:

FIG. 3 shows one embodiment of a user-device. In some embodiments, theuser-device may be made portable; mobile; and/or wearable.

A user-device may include a digital processor 30 and local storagememory 33. The digital processor 30 incorporates and executes theprocessing program to process the composition data. The memory 33 mayhold composition data; software (program) code; and working storage.

The digital processor 30 may be implemented with any digital processinghardware such as Digital processors, Central Processing Units (CPU),Digital Signal Processors (DSP), state machines, controllers,micro-controllers, Integrated Circuits (IC's), Custom IntegratedCircuits, Application Specific Integrated Circuits (ASIC's),Programmable Logic Devices (PLD's), Complex Programmable Logic Devices(CPLD's), Field Programmable Gate Arrays (FPGA's), ElectronicRe-Programmable Gate-Arrays/Circuitry and any other type of digitallogic circuitry/memory.

If the processor is comprised of programmable-circuitry [e.g.,electronically re-configurable gate-array/circuitry], the processingprogram (or portions of the processing program) may be incorporated intothe downloadable digital logic configuration of the gate array(s).

In some embodiments, the digital processor may comprise a plurality ofprocessors in a multi-processing arrangement which may execute thesequences of instructions contained in memory 33.

The memory 33 may be implemented using random access memory (e.g., DRAM,SRAM), registers, register files, flip-flops, integrated circuit storageelements, and storage media such as disc, or even some combination ofthese. The memory 33 may include a non-volatile memory to store boot-updata and other data locally. The memory 33 may optionally include a harddrive or other mass storage device. Software code; processing programs;firmware; hardware configuration data; composition data and other datamay be stored in the memory 31.

The user-device may optionally include a media drive to allow bothcomposition data and processing programs to be read from media.

The user-device may optionally include a network interface 31 to allowaccess to the Internet, other networks or mobile type networks. Thiswould allow composition data and the processingprograms/software/firmware to be downloaded across the Internet or othernetwork(s).

Additional Approaches:

In some embodiments, hard-wired circuitry and/or programmable-circuitrymay be used in place of or in combination with software instructions.Thus, embodiments may include any combination of hardware circuitry andsoftware/firmware.

The processor software, machine-language executable instructions,machine-interpretable instructions, firmware, and/or theconfiguration-data base of electronically-configurable-circuitry: may bestored on/in one or more computer-readable medium/media, and/or one ormore digital storage memories.

Depending on the embodiment, the computer-readable medium may include:nonvolatile media, volatile media, and transmission media. Nonvolatilemedia include, for example, optical or magnetic disks, such as mediadrive 105. Volatile media include dynamic memory (e.g., DRAM).Transmission media include coaxial cables, copper wire, and fiberoptics, including the wires that comprise an interface/communicationsbus. Transmission media can also take the form of acoustic or lightwaves, such as those generated during radio frequency (RF) and infrared(IR) data communications.

In some embodiments, the computer-readable media may include: floppydisk, a flexible disk, hard disk, magnetic tape, any other type ofmagnetic medium; Compact Disk (CD), CD-ROM, CD-RAM, CD-R, CD-RW, DVD,DVD+-R, DVD+-RW, DVD-RAM, and any other type of optical medium; punchcards, paper tape, any other physical medium with patterns of holes;RAM, DRAM, SRAM, PROM, EPROM, EEPROM, Flash-memory, FLASH EPROM, and anyother type of memory chip/cartridge; or any other type of storage ormemory from which a processor/computer can obtain its digital contents.

More Applications and Uses:

In order to more clearly illustrate functionality, portions of thepreceding discussion were oriented toward a user-device 22 with amanually controlled interface. But, more generally, any type of userinterface may be used, including a voice controlled user interface.

In order to more clearly illustrate functionality, portions of theforegoing discussion were described in terms of music and/or musicvideos. But, more generally, may be implemented to generate any type ofpersonalized entertainment experience that is customized for each user.The entertainment experience that is personalized for each user may becomprised of a sequence of any type of entertainment compositionsincluding music, music videos, short films, movies, video programs,audio versions of books, talks, speeches, voice content, lectures, etc.

Additional Embodiments:

One embodiment may be described by the following:

-   -   An apparatus-implemented method of distributing a digital-work        to a plurality of user-devices that use different formats, the        method comprising:        -   storing a definition of usage-rights for said digital-work            in one or more memories; wherein said definition of            usage-rights authorizes a plurality of different formats of            a digital-work for use by a user, at a plurality of            different user-devices; wherein one user-device uses a            different format from another user-device;        -   determining when the user who is authorized to utilize said            usage-rights is present at one of the user-devices;        -   selecting, automatically by a processor, a format of the            digital-work, from a plurality of available formats, which            is most appropriate for the user-device where the user is            present;        -   sending onto a network to said user-device: the selected            format of said digital-work that is compatible with said            user-device and an authorization to utilize the selected            format of the digital-work; and    -   whereby said digital-work is automatically available at any of a        plurality of user-devices that said authorized user is present        at.

The above embodiment may be further enhanced by the addition of one ormore of the following elements or features, either individually orcombined together:

-   -   wherein the authorization sent to the user-device expires,        before the definition of usage-rights expires.    -   wherein the authorization, sent to the user-device, expires        after a time period that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device, expires after        an amount of usage, that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device, expires after        a number of times used, that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device expires,        unless the authorization sent to the user-device is re-newed        from time to time.    -   wherein the authorization sent to the user-device, expires after        a time period, unless appropriate feedback on the usage of the        digital-work has been sent by the user-device.    -   wherein the selected format and authorization are sent to the        user-device in anticipation of future use, by the user, of the        digital-work at a user-device.    -   wherein, based on a history and/or context of the user, the        selected format and the authorization is sent to said        user-device before being needed or requested by the user.    -   wherein after determining the user is present at the        user-device:        -   determining that a digital-work, for which the user has            usage-rights, is expected to be used in the future by the            user at the user-device;        -   determining if the digital-work and authorization is already            available, for use by the user at the user-device; and        -   if the selected format and/or authorization is not already            available at the user-device, automatically without needing            user action or initiation, sending the selected format            and/or the authorization to the user-device before being            needed by the user at the user-device.    -   wherein: after determining the user is present at the        user-device:        -   determining, automatically without needing user initiation            or action, that a digital-work for which the user has            usage-rights, is not configured for use by the user at the            user-device; and        -   sending the selected format and/or the authorization for use            by the user, to the user-device before being needed by the            user at the user-device.    -   further comprising: when a network connection is not available        to the user-device, maintaining the ability of the user to use        the digital-work at the user-device, by utilizing the        digital-work and the authorization that was previously sent to        the user-device.    -   wherein the user is able to use the digital-work and the        authorization that was previously received at the user-device,        during times when a network connection is not available to the        user-device.    -   wherein, after the digital-work and authorization have been        received at the user-device, the user is able to utilize the        digital-work at the user-device during times when the network        connection is not available.    -   wherein the actual identity of the user remains unknown to        experience-providers, digital-work providers and usage-rights        repositories.    -   wherein the definition of usage-rights for the digital-work is        stored at one or more locations on the network; and wherein the        definition of usage-rights is accessed, across the network, by a        plurality of different experience-providers.    -   wherein a version indicator or characteristics of the        user-device, are sent across the network to a        experience-provider, automatically without needing user action        or initiation; and wherein the format of the digital-work and        the authorization, that is most appropriate for the user-device,        is sent across the network to the user-device.    -   further comprising: using said authorization to enable, the        selected format of the digital-work, to be used at said        user-device.    -   wherein said selecting occurs without the user doing the        selecting.    -   wherein information received from the user-device, is used in        said selecting of the most appropriate format for the        user-device.    -   wherein the definition of usage-rights includes a right to use        formats that already exist and formats that are developed or        released in the future.    -   wherein the digital-work is an audio or video composition and        the selected format is an audio format or a video format.    -   wherein the digital-work is an image or display composition and        the selected format is an image format or a display format.    -   wherein the digital-work is an entertainment composition and the        selected format is a playback format.    -   further comprising:        -   selecting a most appropriate format for a second user-device            which is different from the format selected for a first            user-device; and        -   sending onto a network to the second user-device, the format            and authorization which was most appropriate for the second            user-device.    -   wherein the most appropriate format is the highest quality        format that is compatible with the user-device.    -   wherein the most appropriate format is the highest quality        format that is: available to send to the user-device and is        compatible with the user-device.

One embodiment may be described by the following:

-   -   Apparatus for distributing a digital-work to a plurality of        user-devices that use different formats, the apparatus        comprising:        -   one or more memories that store a definition of usage-rights            for said digital-work; wherein said definition of            usage-rights authorizes a plurality of different formats of            a digital-work for use by a user, at a plurality of            different user-devices; wherein one user-device uses a            different format from another user-device;        -   one or more processors to:            -   determine when the user who is authorized to utilize                said usage-rights is present at one of the user-devices;                and            -   automatically select a format of the digital-work, from                a plurality of available formats, which is most                appropriate for the user-device where the user is                present;        -   at least one network interface to send onto a network to            said user-device: the selected format of said digital-work            that is compatible with said user-device and an            authorization to utilize the selected format of said            digital-work; and        -   whereby said digital-work is automatically available at any            of a plurality of user-devices that said authorized user is            present at.

The above embodiment may be further enhanced by the addition of one ormore of the following elements or features, either individually orcombined together:

-   -   wherein the authorization sent to the user-device expires,        before the definition of usage-rights expires.    -   wherein the authorization, sent to the user-device, expires        after a time period that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device, expires after        an amount of usage, that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device, expires after        a number of times used, that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device expires,        unless the authorization sent to the user-device is re-newed        from time to time.    -   wherein the authorization sent to the user-device, expires after        a time period, unless appropriate feedback on the usage of the        digital-work has been sent by the user-device.    -   wherein the selected format and authorization are sent to the        user-device in anticipation of future use, by the user, of the        digital-work at a user-device.    -   wherein, based on a history and/or context of the user, the        selected format and the authorization is sent to said        user-device before being needed or requested by the user.    -   wherein after determining the user is present at the        user-device:        -   determining that a digital-work, for which the user has            usage-rights, is expected to be used in the future by the            user at the user-device;        -   determining if the digital-work and authorization is already            available, for use by the user at the user-device; and        -   if the selected format and/or authorization is not already            available at the user-device, automatically without needing            user action or initiation, sending the selected format            and/or the authorization to the user-device before being            needed by the user at the user-device.    -   wherein: after determining the user is present at the        user-device:        -   determining, automatically without needing user initiation            or action, that a digital-work for which the user has            usage-rights, is not configured for use by the user at the            user-device; and        -   sending the selected format and/or the authorization for use            by the user, to the user-device before being needed by the            user at the user-device.    -   wherein the user is able to use the digital-work and the        authorization that was previously received at the user-device,        during times when a network connection is not available to the        user-device.    -   wherein, after the digital-work and authorization have been        received at the user-device, the user is able to utilize the        digital-work at the user-device during times when the network        connection is not available.    -   wherein the actual identity of the user remains unknown to        experience-providers, digital-work providers and usage-rights        repositories.    -   wherein the definition of usage-rights for the digital-work is        stored at one or more locations on the network; and wherein the        definition of usage-rights is accessed, across the network, by a        plurality of different experience-providers.    -   wherein a version indicator or characteristics of the        user-device, are sent across the network to a        experience-provider, automatically without needing user action        or initiation; and wherein the format of the digital-work and        the authorization, that is most appropriate for the user-device,        is sent across the network to the user-device.    -   wherein said selecting occurs without the user doing the        selecting.    -   wherein information received from the user-device, is used in        said selecting of the most appropriate format for the        user-device.    -   wherein the definition of usage-rights includes a right to use        formats that already exist and formats that are developed or        released in the future.    -   wherein the digital-work is an audio or video composition and        the selected format is an audio format or a video format.    -   wherein the digital-work is an image or display composition and        the selected format is an image format or a display format.    -   wherein the digital-work is an entertainment composition and the        selected format is a playback format.    -   wherein the most appropriate format is the highest quality        format that is compatible with the user-device.    -   wherein the most appropriate format is the highest quality        format that is: available to send to the user-device and is        compatible with the user-device.

One embodiment may be described by the following:

-   -   One or more computer-readable memories or storage media, not        including carrier-waves, having computer-readable instructions        thereon which, when executed by one or more processing devices,        implement a method of distributing a digital-work to a plurality        of user-devices that use different formats, the method        comprising:        -   storing a definition of usage-rights for said digital-work            in one or more memories; wherein said definition of            usage-rights authorizes a plurality of different formats of            a digital-work for use by a user, at a plurality of            different user-devices; wherein one user-device uses a            different format from another user-device;        -   determining when a user who is authorized to utilize said            usage-rights is present at one of the user-devices;        -   selecting, automatically by a processor, a format of the            digital-work, from a plurality of available formats, which            is most appropriate for the user-device where the user is            present;        -   sending onto a network to said user-device: the selected            format of said digital-work that is compatible with said            user-device and an authorization to utilize the selected            format of the digital-work; and        -   whereby said digital-work is automatically available at any            of a plurality of user-devices that said authorized user is            present at.

The above embodiment may be further enhanced by the addition of one ormore of the following elements or features, either individually orcombined together:

-   -   wherein the authorization sent to the user-device expires,        before the definition of usage-rights expires.    -   wherein the authorization, sent to the user-device, expires        after a time period that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device, expires after        an amount of usage, that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device, expires after        a number of times used, that is less than the definition of        usage-rights.    -   wherein the authorization sent to the user-device expires,        unless the authorization sent to the user-device is re-newed        from time to time.    -   wherein the authorization sent to the user-device, expires after        a time period, unless appropriate feedback on the usage of the        digital-work has been sent by the user-device.    -   wherein the selected format and authorization are sent to the        user-device in anticipation of future use, by the user, of the        digital-work at a user-device.    -   wherein, based on a history and/or context of the user, the        selected format and the authorization is sent to said        user-device before being needed or requested by the user.    -   wherein after determining the user is present at the        user-device:        -   determining that a digital-work, for which the user has            usage-rights, is expected to be used in the future by the            user at the user-device;        -   determining if the digital-work and authorization is already            available, for use by the user at the user-device; and        -   if the selected format and/or authorization is not already            available at the user-device, automatically without needing            user action or initiation, sending the selected format            and/or the authorization to the user-device before being            needed by the user at the user-device.    -   wherein: after determining the user is present at the        user-device:        -   determining, automatically without needing user initiation            or action, that a digital-work for which the user has            usage-rights, is not configured for use by the user at the            user-device; and        -   sending the selected format and/or the authorization for use            by the user, to the user-device before being needed by the            user at the user-device.    -   further comprising: when a network connection is not available        to the user-device, maintaining the ability of the user to use        the digital-work at the user-device, by utilizing the        digital-work and the authorization that was previously sent to        the user-device.    -   wherein the user is able to use the digital-work and the        authorization that was previously received at the user-device,        during times when a network connection is not available to the        user-device.    -   wherein, after the digital-work and authorization have been        received at the user-device, the user is able to utilize the        digital-work at the user-device during times when the network        connection is not available.    -   wherein the actual identity of the user remains unknown to        experience-providers, digital-work providers and usage-rights        repositories.    -   wherein the definition of usage-rights for the digital-work is        stored at one or more locations on the network; and wherein the        definition of usage-rights is accessed, across the network, by a        plurality of different experience-providers.    -   wherein a version indicator or characteristics of the        user-device, are sent across the network to a        experience-provider, automatically without needing user action        or initiation; and wherein the format of the digital-work and        the authorization, that is most appropriate for the user-device,        is sent across the network to the user-device.    -   further comprising: using said authorization to enable, the        selected format of the digital-work, to be used at said        user-device.    -   wherein said selecting occurs without the user doing the        selecting.    -   wherein information received from the user-device, is used in        said selecting of the most appropriate format for the        user-device.    -   wherein the definition of usage-rights includes a right to use        formats that already exist and formats that are developed or        released in the future.    -   wherein the digital-work is an audio or video composition and        the selected format is an audio format or a video format.    -   wherein the digital-work is an image or display composition and        the selected format is an image format or a display format.    -   wherein the digital-work is an entertainment composition and the        selected format is a playback format.    -   further comprising:        -   selecting a most appropriate format for a second user-device            which is different from the format selected for a first            user-device; and        -   sending onto a network to the second user-device, the format            and authorization which was most appropriate for the second            user-device.    -   wherein the most appropriate format is the highest quality        format that is compatible with the user-device.    -   wherein the most appropriate format is the highest quality        format that is: available to send to the user-device and is        compatible with the user-device.

More Additional Embodiments:

One embodiment may be described by the following:

-   -   An apparatus-implemented method for personalized music or        entertainment, the method comprising:        -   capturing, at a user-device, details of control actions by a            user on pieces or compositions;        -   storing in one or more memories, a plurality of ratings            associated with the user; wherein a rating, indicating a            magnitude of preference of the user, is associated with a            piece or composition; wherein the magnitude of the rating            for the associated piece or composition was determined by            using at least some of the details of said control actions            by the user on the associated piece or composition; and        -   automatically selecting at least one piece or composition            for playback, by using a relationship that defines a time            between playbacks of the selected piece or composition,            which varies with the magnitude of said rating of the user            for the selected piece or composition.

Another embodiment may be described by the following:

-   -   An apparatus-implemented method for personalized music or        entertainment, the method comprising:        -   capturing, at a user-device, details of control actions by a            user on pieces or compositions; wherein said details include            a number of times a piece or composition was heard by the            user;        -   storing in one or more memories, a plurality of ratings            associated with the user; wherein a rating, indicating a            magnitude of preference of the user, is associated with a            piece or composition; wherein the magnitude of the rating            for the associated piece or composition was determined by            using at least some of the details of said control actions            by the user on the associated piece or composition; and        -   automatically selecting at least one piece or composition            for playback, by using a relationship that defines a time            between playbacks of the selected piece or composition which            varies with: the magnitude of said rating of the user for            the selected piece or composition, or the number of times            the selected piece or composition was heard by the user.

Another embodiment may be described by the following:

Apparatus for personalized music or entertainment, said apparatuscomprising:

-   -   means for capturing at a user-device, details of user actions by        a user;    -   one or more memories that store, a plurality of ratings        associated with the user; wherein a rating, indicating a        magnitude of preference of the user, is associated with a piece        or composition; wherein the magnitude of the rating for the        associated piece or composition was determined by using at least        some of the details of said user actions by the user on the        associated piece or composition; and    -   a processor that automatically selects at least one piece or        composition for playback, by using a relationship that defines a        time between playbacks of the selected piece or composition        which varies with the magnitude of said rating of the user for        the selected piece or composition.

Another embodiment may be described by the following:

-   -   One or more computer-readable memories or media, not including        carrier-waves, having computer-readable instructions thereon        which, when executed by one or more processing devices,        implement a method of:        -   capturing, at a user-device, details of control actions by a            user on pieces or compositions; wherein said details include            a number of times a piece or composition was heard by the            user;        -   storing in one or more memories, a plurality of ratings            associated with the user; wherein a rating, indicating a            magnitude of preference of the user, is associated with a            piece or composition; wherein the magnitude of the rating            for the associated piece or composition was determined by            using at least some of the details of said control actions            by the user on the associated piece or composition; and        -   automatically selecting at least one piece or composition            for playback, by using a relationship that defines a time            between playbacks of the selected piece or composition which            varies with: the magnitude of said rating of the user for            the selected piece or composition, or the number of times            the selected piece or composition was heard by the user.

Any of above four embodiments may be further enhanced by the addition ofone or more of the following elements or features, either individuallyor combined together:

-   -   further comprising: automatically initiating the playback of        said selected piece or composition for said user.    -   wherein said relationship defines a plurality of different        values for the time between playbacks.    -   wherein said relationship is defined by a curve.    -   wherein said relationship is defined by a lookup table or        database.    -   wherein said relationship is defined by an equation or a        mathematical function.    -   wherein said relationship is non-linear.    -   wherein said relationship is monotonic.    -   wherein said relationship is not monotonic.    -   wherein the more favorable a rating for a piece or composition,        the time between playbacks of the piece or composition is        shorter.    -   wherein, when a said user's rating for an a said piece or        composition is below a defined level of preference, the said        piece or composition is not selected again until at least a        defined amount of time has elapsed from a prior playback of the        said piece or composition.    -   wherein when a user's rating for a said piece or composition is        below a defined level of preference, that piece or composition        is not selected.    -   wherein said control actions are user actions that affect a        playback of a piece or composition during its playback.    -   wherein said control actions are user actions to repeat or        replay, a piece or composition that previously played; and        wherein a said user's rating is adjusted to a higher preference,        by a said user control action or actions to repeat or replay,        the piece or composition.    -   wherein said control actions are user actions to find, select or        designate, a particular piece or composition for playback; and        wherein a said user's rating is adjusted to a higher preference,        by a user control action that finds, selects or designates the        piece or composition for playback.    -   wherein said control actions are user actions to search or find        a specific piece or composition; wherein a said user's rating is        adjusted to a higher preference, by a said user control actions        to search or find the specific piece or composition.    -   wherein said control actions are user actions to skip or        forward-past an ending portion of a currently playing piece or        composition; and wherein a said user's rating is adjusted to a        lower preference, by a user control action or actions that skip        or forward-past, the ending portion of the piece or composition        that is currently playing.    -   wherein said control actions are user actions to stop a        currently playing piece or composition; and initiate playback of        another piece or composition; wherein a said user's rating        associated with the playing piece or composition is adjusted to        a lower preference, by a user control action or actions that        stop the piece or composition that is playing; and initiate        playback of another piece or composition.    -   wherein said control actions are user actions to cause a piece        or composition that has finished playing, to start playing        again; wherein a said user's rating is adjusted to a higher        preference, by a said user control action or actions to start        playing again.    -   wherein the sooner said user takes control action, to stop a        currently playing piece or composition, in-order to experience        another piece or composition; the more the rating for the        stopped piece or composition, is adjusted to a lower preference.    -   wherein the sooner the user takes control action to avoid a        piece or composition that is playing, the more the rating, for        the avoided piece or composition, is adjusted toward a lower        preference.    -   wherein, once a piece or composition has played for at least a        recognition-time, the sooner a control action to avoid the piece        or composition, the more the rating, for the avoided piece or        composition, is adjusted toward a lower preference.    -   further comprising: playing a sequence of said selected pieces        or compositions, when there are no user control actions        available to be applied or satisfied.    -   further comprising: automatically playing by a user-device, a        sequence of pieces or compositions; wherein the pieces or        compositions were custom selected for said user by using the        ratings associated with the user.    -   wherein the rating for a specific piece or composition is        determined by using a plurality of control actions that occurred        on a plurality of different occasions, and were applied by the        user on the specific piece or composition.    -   wherein a rating for a specific piece or composition is        determined using a plurality of individual said user control        actions that occurred on a plurality of different occasions        and/or at different user-devices; wherein said control actions        were applied to the specific piece or composition.    -   wherein the magnitude of the rating for a piece or composition        is increased by some control actions, and the magnitude of the        rating for a piece or composition is decreased by other control        actions.    -   wherein some user control actions cause the rating to be        adjusted to a higher magnitude, and other user control actions        cause the rating to be adjusted to a lower magnitude.    -   further comprising: adjusting the magnitude of a said user's        rating to a more favorable preference due to control actions        that occurred on a first occasion; and adjusting the magnitude        of a said user's rating to a less favorable preference due to        control actions that occurred on a second occasion.    -   wherein a rating is stored in one or more memories until a        magnitude of the rating is updated by control actions that are        more recent.    -   wherein a said user's rating is updated by adjusting the        magnitude of a prior rating, toward a higher or lower        preference, based on the details of a newer user control action        that was applied to the piece or composition.    -   further comprising:        -   storing, in a memory or memories, the details about            individual control actions, for a plurality of control            actions on a said piece or composition, that occurred on            different occasions and/or at different user devices;        -   processing, in order of control action occurrence, a            plurality of said stored details about control actions, to            determine the magnitude of the rating for the piece or            composition.    -   further comprising:        -   storing, in a memory or memories, the details about            individual control actions, for a plurality of control            actions on a said piece or composition, that occurred on            different occasions and/or at different user devices;        -   processing, in order of control action occurrence, a            plurality of said stored details about control actions to            determine the magnitude of the rating for the piece or            composition; wherein the user's rating is adjusted toward a            more favorable magnitude by some control actions; and            wherein the rating is adjusted to a less favorable magnitude            by other control actions.

Not Limited to Detailed Illustrations:

To satisfy the requirements for enablement, this disclosure may containone or more embodiments which illustrate a particular detailedimplementation and use. A detailed illustration often requires choosingonly one of a plurality of equivalent detail approaches to show. Whenterms such as “shall”, “should”, “is”, “are” appear, they should only beinterpreted as limitations/requirements for the purpose of maintainingcompatibility/consistency between the elements/parameters of theparticular detailed illustration. Such terms should not be interpretedas limitations or requirements on the scope of the general concepts asdisclosed in their entirety.

For example, if element “A”, in a detailed embodiment, is shown ashaving a certain detailed configuration, then mating element “B” in thatdetailed example may need to have corresponding limitations in-order tobe compatible/interoperable with the detailed element “A”. Suchlimitations on element “B” for compatibility within a detailedillustration do not define limitations on element “B” within all thepossible embodiments that fall within the scope of the claims. Ifanother embodiment had been chosen for illustration purposes, element“A” may have a very different detailed configuration and therequirements on element “B” for compatible/interoperable with theelement “A” may be very different.

In general, the detailed implementations for the elements in theillustrated embodiments may have many alternate implementations thataccomplish the same functional result/objective and are within the scopeof the claims.

1-33. (canceled)
 34. Apparatus for personalized music or entertainment,the apparatus comprising: circuitry to capture user-actions, associatedwith a music or entertainment composition, applied or made by a user;electronic-circuitry and/or processor(s) that: determine or utilize, atarget time for presentation or playback of said composition to saiduser, that is at least partially based on a relationship(s) that is atleast partially based on: a time when said composition was previouslyplayed or presented to said user, one or more values for a time betweenpresentations or playbacks of said composition to said user, and one ormore said captured user-actions by said user that are associated withsaid composition; initiate a presentation or playback of saidcomposition to said user, at least partially based on said target timefor presentation or playback.
 35. Apparatus as in claim 34 wherein saidcaptured user-actions are captured at a plurality of user-devices. 36.Apparatus as in claim 34 wherein said target time for presentation orplayback is determined by using a plurality of said captureduser-actions that were captured on a plurality of different occasions,when applied or made by the user on said composition.
 37. Apparatus asin claim 34 wherein said electronic-circuitry and/or processor(s) areconfigured to also: play or present a personalized sequence thatincludes other compositions; wherein said composition is included insaid sequence, at least partially based upon said target time forpresentation or playback of said composition.
 38. Apparatus as in claim34 wherein said electronic-circuitry and/or processor(s) are configuredto also: select said composition for presentation or playback as part ofa sequence of compositions for said user, at least partially based onsaid target time for presentation or playback of said composition tosaid user.
 39. Apparatus as in claim 34 wherein said relationshipincludes a plurality of different values for said time betweenpresentations or playbacks.
 40. Apparatus as in claim 34 wherein saidrelationship includes three or more values for said time betweenpresentations or playbacks.
 41. Apparatus as in claim 34 wherein atleast a portion of said relationship includes component(s) that arenon-linear components with said user-actions.
 42. Apparatus as in claim34 wherein at least a portion of said relationship includes component(s)that are monotonic with said user-actions.
 43. Apparatus as in claim 34wherein at least a portion of said relationship includes component(s)that are not monotonic with said user-actions.
 44. Apparatus as in claim34 wherein at least a portion of said relationship is defined bycurve(s), lookup table(s), database, equation, polynomial, digitaldifferential analyzer, mathematical function or formula.
 45. Apparatusas in claim 34 wherein said target time for presentation or playback, isat least partially determined by adjusting a prior value of a timebetween presentations or playbacks, by an amount that varies with one ormore said captured user-actions.
 46. Apparatus as in claim 34 whereinsaid target time for presentation or playback, is at least partiallydetermined by adjusting a prior value of a time between presentations orplaybacks, by an amount that varies with a plurality of said captureduser-actions.
 47. Apparatus as in claim 34 wherein said target time forpresentations or playbacks: is made sooner in time by some said captureduser-actions, and is made further off in time by other said captureduser-actions.
 48. Apparatus as in claim 34 wherein said captureduser-actions associated with said composition, are processed in theirorder of occurrence; wherein said target time for presentations orplaybacks: is made sooner in time by some said captured user-actions,and is made further off in time by other said captured user-actions. 49.Apparatus as in claim 34 wherein said target time for presentation orplayback, is made sooner in time by said captured user-action(s) thatfind, select or designate, said composition for presentation orplayback.
 50. Apparatus as in claim 34 wherein said target time forpresentations or playbacks, is made sooner in time by said captureduser-action(s) that search or find said composition.
 51. Apparatus as inclaim 34 wherein said target time for presentations or playbacks, ismade sooner in time by said captured user-action(s) that repeat thepresentation or playback of said composition.
 52. Apparatus as in claim34 wherein said target time for presentations or playbacks, is madesooner in time by said captured user-action(s) that indicate: athumbs-up, a like, play more frequently, or that increase their ratingor preference for said composition.
 53. Apparatus as in claim 34 whereinsaid target time for presentations or playbacks, is made sooner in timeby said captured user-action(s) which indicate that said user hasrecommended said composition to another person.
 54. Apparatus as inclaim 34 wherein said target time for presentations or playbacks, ismade sooner in time by said captured user-action(s) that imply afavorable preference of said user for said composition.
 55. Apparatus asin claim 34 wherein said target time for presentations or playbacks, ismade sooner in time by said captured user-action(s) that are implicitand imply a favorable preference of said user for said composition. 56.Apparatus as in claim 34 wherein said target time for presentations orplaybacks, is made further away in time by said captured user-action(s)that skip or forward-past, an ending portion of said composition. 57.Apparatus as in claim 34 wherein said target time for presentations orplaybacks, is made further away in time by said captured user-action(s)that stopped said composition while being played or presented; andinitiated presentation or playback of another composition.
 58. Apparatusas in claim 34 wherein said target time for presentations or playbacks,is made further away in time by said captured user-action(s) thatindicate a thumbs-down, a dis-like, or that decrease their rating orpreference for said composition.
 59. Apparatus as in claim 34 whereinsaid target time for presentations or playbacks, is made further away intime by said captured user-action(s) that imply a dislike of said userfor said composition.
 60. Apparatus as in claim 34 wherein said targettime for presentations or playbacks, is made further away in time bysaid captured user-action(s) that are implicit and imply a dislike ofsaid user for said composition.
 61. Apparatus as in claim 34 whereinsaid target time for presentations or playbacks, is made further away intime at least partially based on how soon said user applied or made,said captured user-action(s) that avoid said composition.
 62. Anapparatus-implemented method for personalized music or entertainment,comprising: capturing, by circuitry, user-actions associated with amusic or entertainment composition, applied or made by a user;determining or utilizing, by a electronic-circuitry and/or processor(s),a target time for presentation or playback of said composition to saiduser, that is at least partially based on a relationship(s) that is atleast partially based on: a time when said composition was previouslyplayed or presented to said user, one or more values for a time betweenpresentations or playbacks of said composition to said user, and one ormore said captured user-actions by said user that are associated withsaid composition; initiating, by a electronic-circuitry and/orprocessor(s), a presentation or playback of said composition to saiduser, at least partially based on said target time for presentation orplayback.
 63. One or more non-transitory computer-readable memories orstorage media, not including carrier-waves, having computer-readableinstructions stored thereon which, when executed by electronic-circuitryand/or processor(s), implement a method for personalized music orentertainment, the method comprising: capturing, by circuitry,user-actions associated with a music or entertainment composition,applied or made by a user; determining or utilizing, by aelectronic-circuitry and/or processor(s), a target time for presentationor playback of said composition to said user, that is at least partiallybased on a relationship(s) that is at least partially based on: a timewhen said composition was previously played or presented to said user,one or more values for a time between presentations or playbacks of saidcomposition to said user, and one or more said captured user-actions bysaid user that are associated with said composition; initiating, by aelectronic-circuitry and/or processor(s), a presentation or playback ofsaid composition to said user, at least partially based on said targettime for presentation or playback.